Wow ... that was that and I would never ever had the idea to change
the way classes are enhanced !
So, now the classes are enhanced at build time it all works fine.
I add my voice to the doc, runtime dynamic enhancement are just for
quick test, anything serious need build time enhancement.
I can tell OpenJPA rocks, what I did had been tested impossible to do
with other frameworks.
Thanks a lot.
On Aug 4, 2009, at 15:25 , Michael Dick wrote:
Hi Jean-Baptiste,
The stack shows that you're using OpenJPA's automatic enhancement
mechanism
(subclassing). Have you tried using build time enhancement [1]?
[1] http://openjpa.apache.org/entity-enhancement.html
-mike
On Tue, Aug 4, 2009 at 7:58 AM, Jean-Baptiste BRIAUD -- Novlog <
[email protected]> wrote:
One more precision : it is not failling if I call getField() but
apparently
only if field is a collection and if I call .size() method.
Could that be a bug somewhere in enhancement or proxy of collection ?
To illustrate : an exemple where A has a collection of B :
// Here, A had been detached and entity manager had been closed
// Note that B had not explicitly detached.
// The collection of A came from a query "SELECT a FROM A a" but
with a
fetch plan to restrict B and other values not to be retreived.
for(A a : collection of A) {
B bs = a.getB(); // is not null but can't be evaluated in the
debugger due
to a NPE even if the console do not show any stack
if (bs != null) {
// SO we're going here because bs is not null. Don't know
what's
inside as it can't be evaluated in the debugger.
bs.size(); // NPE is here in the console and also in the
debugger.
}
}
Here is the stack :
NullPointerException : The exception has no message in it
java.lang.NullPointerException
at
org.apache.openjpa.enhance.p$q$A$pcsubclass.pcReplaceField(Unknown
Source)
at
org
.apache
.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:
3025)
at
org
.apache
.openjpa
.kernel.StateManagerImpl.storeStringField(StateManagerImpl.java:2498)
at
org
.apache
.openjpa.kernel.StateManagerImpl.storeString(StateManagerImpl.java:
2489)
at
org
.apache
.openjpa
.jdbc.meta.strats.StringFieldStrategy.load(StringFieldStrategy.java:
155)
at
org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:813)
at
org
.apache
.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:
1056)
at
org
.apache
.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:
1008)
at
org
.apache
.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:678)
at
org
.apache
.openjpa
.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
at
org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:
78)
at
org
.apache
.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:
2921)
at
org
.apache
.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:
2999)
at
org
.apache
.openjpa
.kernel.StateManagerImpl.fetchObjectField(StateManagerImpl.java:2242)
at
org
.apache
.openjpa.kernel.StateManagerImpl.fetchField(StateManagerImpl.java:
778)
at
org
.apache.openjpa.kernel.StateManagerImpl.fetch(StateManagerImpl.java:
740)
at
org.apache.openjpa.enhance.RedefinitionHelper
$1.invoke(RedefinitionHelper.java:230)
at $Proxy21.size(Unknown Source)
On Aug 4, 2009, at 14:41 , Jean-Baptiste BRIAUD -- Novlog wrote:
it is still failling !
After detaching and even closing the entity manager, accessing a not
retreived field using fetch plan cause a NPE in pcReplaceField ...
I'm completly blocked and in the dark ... I even don't see where
investigating more now ...
Any idea ?
On Aug 4, 2009, at 11:51 , Jean-Baptiste BRIAUD -- Novlog wrote:
On Aug 4, 2009, at 03:06 , Michael Dick wrote:
Hi,
Have you tried detaching your entities? When an entity is detached
OpenJPA
won't go to the database to load a field. So we'll return null for
anything
that isn't in your fetch group (exception : if you load the
field prior
to
detaching then it will be available).
This is a good point and it had worked, but I'm puzzled : I thought
closing the entityManager will detach managed entities ... and
apparently it
is not the case.
If I want to detach entity, I have to detach it explicitly, I
didn't spot
that.
You can detach by calling EntityManager.clear() or
OpenJPAEntityManager.detach(Object o). Either way it'll be a lot
easier
than
creating your own proxy class.
Sure, it is a *lot* more easier :-)
I'm using detachAll to detach a full collection at once.
I'm not sure about the behavior of clear(), should clear all
managed
entity ?
By the way, this detach behavior will be ammended in version 2.x,
I might
try this version, but I feel it could be risky ... On the other
hand, my
project's time frame fit well with this version 2.
Any feedback on 2.0 relliability ?
Hope this helps,
It solve the problem, big big thanks !
-mike
Jean-Baptiste BRIAUD -- Novlog wrote:
Hi,
My question is "is there simpler things to do ?"
Please, review that idea and don't hesitate to comment ...
Step 1 : I want partial object, not hashtables. It could be a
Person
with only some attributes having values.
this concern not only @Basic attribute but also any relational
attributes like @ManyToOne, ...
=> I used fetch plan and it works fine.
Step 2 : I'm using an Apache lib via a third party framework that
explore all accessors (beanutils).
Unfortunatly, unretreived attributes came with a proxy.
As a consequence, all unreitreived attributes are now retreived
wasting all the benefit of having used fetch plan ...
Step 3 : I first try to get rid of that proxies but without
success,
so I though I could just have my own proxy that could subclass
the
OpenJPA default proxy
and just ensure in my subclass that when I need no proxy, the
default
behavior is bypassed.
What do you think about that idea ?
--
View this message in context:
http://n2.nabble.com/Custom-proxy-%3A-idea-review-needed-tp3376839p3381672.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
