|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Metabug
|
|
This issue is covered under:
|
|
SFOS-1097
LoadClass to provide better diagnostics when a class is not found
|
|
|
|
|
|
|
|
|
Because the JVM is so uninformative on ClassNotFoundExceptions, when there is trouble with classpaths, much time can be wasted tracking down the problem.
1. PrimImpl could handle such exceptions by adding in lots more diagnostics.
2., we have a org.smartfrog.services.os.java.LoadClassImpl class to help, but even its diagnostics can be improved.
3. we could have a command line command that could deploy a LoadClass instance to test that a class is present
some ideas for better diagnostics
-Look for the resource, using ClassLoader.findResource() to get (and print) the URL of the .class file -and flagging if that file does not exist
-Advanced: look inside the .class file and get the list of imported classes, then look for every such imported class. This can track down (some) missing dependencies, but is not enough for dependencies of parent/constructed classes.
|
|
Description
|
Because the JVM is so uninformative on ClassNotFoundExceptions, when there is trouble with classpaths, much time can be wasted tracking down the problem.
1. PrimImpl could handle such exceptions by adding in lots more diagnostics.
2., we have a org.smartfrog.services.os.java.LoadClassImpl class to help, but even its diagnostics can be improved.
3. we could have a command line command that could deploy a LoadClass instance to test that a class is present
some ideas for better diagnostics
-Look for the resource, using ClassLoader.findResource() to get (and print) the URL of the .class file -and flagging if that file does not exist
-Advanced: look inside the .class file and get the list of imported classes, then look for every such imported class. This can track down (some) missing dependencies, but is not enough for dependencies of parent/constructed classes.
|
Show » |
|
Improvement
Open
Minor
This gives you a ClassNotFoundException for the first class (even though it is on the classpath), instead of a NoClassDefFoundError for the dependency as it should be.
To reproduce, try for example to load AntWorkflowRun with the sf-ant jar on the classpath, but not the ant jar. Or a Scp component without having the jsch jar.
The LoadClassImpl class only helps when components themselves load classes... which they should do with caution with regard to modularity and the OSGi stuff anyway.
But the problem I was describing is more to do with deployers (even though a quick look at PrimDeployerImpl didn't show a catch(Throwable e) { throw new ClassNotFoundException(e); } that I expected to be the cause of the problem.)
Anyway, I feel like class loading problems often happen when creating component instances, so deployers should be looked at too.