Hi Denis, Thank you very much for your report. That's very unfortunate - I'm sure you're on the right track with Spring ASM, although I'm not entirely sure why there's anything that needs compilation at runtime...? Do you know what compiler version this is based on in your case? There were quite a few compiler bugs in the recent past, so I'm not too surprised to see something like that...
One workaround might be to pack all the generated code in a jar file and deliver that to the application. This way (or other similar ways), you would probably be able to prevent this kind of unnecessary compilation step. Lukas 2016-10-24 18:47 GMT+02:00 Denis Miorandi <[email protected]>: > Some more info, running: > > new xxxxxxx.yyy_erp.dbo.tables.People(); TABLE with no converters > new xxxxxxx.yyy_erp.dbo.tables.Companies(); TABLE with converters for > java.time.* > > in a main it works > in jetty+spring, it fails on second row, due to converters, see below. Btw > code is compiled with no errors. I'm suspecting spring asm, > but I don't know. > > > > java.lang.Error: Unresolved compilation problems: > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > The method createField(String, DataType<T>, Table<R>, String, > Converter<T,U>) in the type AbstractTable<CompaniesRecord> is not > applicable for the arguments (String, DataType<Timestamp>, Companies, > String, LocalDateTimeConverter) > > > Il giorno lunedì 24 ottobre 2016 18:07:40 UTC+2, Denis Miorandi ha scritto: >> >> Hi Lukas, >> it happens that query or record stuffs sometimes fails cause >> static table is null. >> >> I.e. createCtx.newRecord(MYTABLE) throw a nullpointer cause MYTABLE is >> null. >> I'm trying to understand if this could be related to jooq or not. Do you >> have any idea that can address me? >> Table.* code is executed when I call query, but tables inside are null. >> Could be due something wrong in jooq context initializing? >> >> My sensation is that is related to my spring dual datasource >> configuration but I want to be sure to exclude jooq, >> also is strange to have a static variable null. I can see that is >> initialized >> >> >> The fact are the following: >> >> - I've got a spring 4.3 environment with jooq 3.8.5 >> - I use @Transactional everywhere for a long time with no problem in >> general >> - Issues start when I use a second database connection+transaction >> manager in spring. Executing same code >> - it never happens in junit code (wrapped in transactional) >> - it happens only when run full code inside jetty container >> - The difference could be about transaction wrapping I suspect >> (from junit and runtime) >> - two jooq context dslGeneral and dslExternal are right addresses to >> connection pool and initialized. The only doubt is about >> using right TM cause I've got a mix of queries in some cases on two >> db, but this at least should be address to run a query with no TM >> not to that issue, I suppose.. >> >> -- > 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.
