|
Sort Order:
The class that was in the classpath is The class that was not in the classpath is so it is the parameter class of a method, that is missing... ok, verified the problem, and we have that since 1.0 already. I am not sure what we can do about that. But we can probably catch the exception and react accordingly. I suspect that a lazy method population algorith - if possible - could slow down the Groovy runtime. I don't know how severe the impact is in practice. Has a custumer who had licensed lib1.jar normally also had licensed the missing lib2.jar? It's maybe a good idea to leave this issue open until it's relevance becomes more clear. it doesn't need to be more lazy that it is atm... we just have to mark the method somehow, so the runtime knows that for this method not all classes are resolved. Any call to such a method results in an error anyway. Hmm, here's part of the stack trace we received: Caused by: java.lang.NoClassDefFoundError: com/sap/jdsr/writer/DsrIPassport From this i concluded that if java.lang.Class.getDeclaredMethods() would throw an error no method of the POJO would be visible from Groovy. hmm.. that's true... I forgot that you can not simply get the method without getting all of them or by knowing the name... in that case I doubt we will find a solution for this.. unless the MetaClass is created in a very different way... like for example by using pre-calculated meta class information as some kind of database. ... or using a different reflection library, if feasible, maybe objectweb asm. objectweb asm is not a reflection library. You need the bytecode for the asm lib, if you do not have it, then you have a problem. Of course the bytecode exists somewhere and there is a way to get it if the class is loaded froma file and the classloader is generous enough to place the informations you need to find the .jar/.class and of course the asm lib has all this builtin already... but there are also cases when there is no file. If the class is generated at runtime or if the class comes from a db or whatever, then it will be a problem... Well unless you know a way to get the bytecode as bye[] at runtime without the need of having the class as file somewhere. I would be very interested in knowing The only place where the original class bytes can be seen is probably within ClassLoaders (where calls to the defineClass methods are made) or instrumentation agents (before defineClass calls). I doubt that the original class byte array is kept in memory by common ClassLoaders. So, given current Groovy byte code, there's probably no chance to fix this bug in an efficient way unless the Java reflection API will provide a way to do so (e.g. by an alternative method iteration pattern, or by lazy instantiation of parameter, return and exception types within the Method class). |
|||||||||||||||||||||||||||||||||||||||
Bug
Open
Major
NoClassDefFoundError as a side effect of a POJO method invocation
can you give an example for the POJO and explain which classes are in the classpath and which classes are not?