Thanks for the update. Interesting, well I'd really love to see that integration with JRebel work. If I can be of any help to you or them, just let me know.
Cheers, Lukas 2015-10-16 17:12 GMT+02:00 jdoe <[email protected]>: > Thank you for your response! > > Settings#setReflectionCaching solved the issue with mapping. You were > very insightful about the cause of the problem! > > Trying to update schema and its related files on fly didn't work well. > Some ClassDefNotFoundError/NoSuchFieldError appear and I think that the > JRebel guys are those that have to be asked about this. > If I have any updates on the issue I'll let you know! > > Thanks again! > > пятница, 16 октября 2015 г., 10:49:19 UTC+3 пользователь Lukas Eder > написал: >> >> Hello, >> >> Very interesting observation, thanks for sharing. jOOQ's Configuration >> maintains a reflection cache, where java.lang.reflect.Field objects and >> similar things are kept around to improve performance. Now, if a >> sophisticated class loader like JRebel's replaces your POJOs, but not the >> Configuration instance, then the cache will be stale. In particular, the >> accessible flag seems to have been reset by JRebel - which might be >> considered a JRebel bug. >> >> A quick workaround would be to not reuse the Configuration instance in >> development, but create it afresh every time, or to turn off reflection >> caching in the Settings. >> >> Let me know if any of these hints help. >> >> Also, I'm curious: How does jOOQ's code generator work with JRebel in >> general? Is it easy to replace the generated tables / records after a >> schema change and update them into a live JVM? Would be very interesting to >> read a blog post about this! >> >> Best Regards, >> Lukas >> >> 2015-10-15 19:01 GMT+02:00 jdoe <[email protected]>: >> >>> Hello! >>> >>> I've trapped into a problem while I'm on the development step: using >>> tools such as JRebel allows me to update beans on fly. >>> When I modify some bean then any following attempts to load it from a DB >>> using the reflection facility provided by DefaultRecordMapper causes >>> the following exception: >>> >>> Caused by: java.lang.IllegalAccessException: Class >>> org.jooq.impl.DefaultRecordMapper$MutablePOJOMapper can not access a member >>> of >>> class com.mycompany.projects.beans.SomeBean$$M$_jr_7E9C8B0F83F2A45B_1 >>> with modifiers "private" >>> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) >>> at >>> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) >>> at >>> java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) >>> at java.lang.reflect.Field.setInt(Field.java:940) >>> at >>> org.jooq.impl.DefaultRecordMapper$MutablePOJOMapper.map(DefaultRecordMapper.java:670) >>> at >>> org.jooq.impl.DefaultRecordMapper$MutablePOJOMapper.map(DefaultRecordMapper.java:636) >>> at >>> org.jooq.impl.DefaultRecordMapper$MutablePOJOMapper.map(DefaultRecordMapper.java:589) >>> ... 112 more >>> >>> Any ideas why the DefaultRecordMapper fails with these weird but >>> eligible beans? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jOOQ User Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
