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. >>>> >>>> >>> >>> >> >> >
