openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste BRIAUD -- Novlog <j-b.bri...@novlog.com>
Subject Re: Custom proxy : idea review needed
Date Tue, 04 Aug 2009 12:58:54 GMT
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.
>>>
>>
>>
>
>


Mime
View raw message