| Susan Hert responded: |
2017-10-04 14:52 |
This being a run-time failure suggests that there's a jar file not being found somewhere.
If you look in your build/deploy/modules/<first module>/lib and build/deploy/modules/<second module>/lib directories do you see the jar files you expect? And does the first module's jar file contain the class that it's not finding?
Susan |
| |
| Matt V responded: |
2017-10-05 09:22 |
They weren't, only in first module's lib, so I copied the jars into both module lib dirs. They are now showing in both directories you listed.
Unfortunately, the same error persists. I think it may be because the class, DBHelper, is part of the first module and not the second. Maybe with the build change, it's now unable to find that at runtime? |
| |
| Susan Hert responded: |
2017-10-05 10:16 |
Sorry for not being clear, Matt. You shouldn't need to copy all the jars into both module's lib directories as both directories' jar files should be on the classpath. Each module's deployed lib directory should contain its own jar file(s) (e.g., compBioStudy-17.2.jar) as well as the jar files of the module's external dependencies.
The Gradle build should be putting all deployed jars into the same place the ant build did, and once the jars are in place the build system's job is done. It shouldn't affect the running server, unless it has put the jar files in a bad place.
Here are a couple of things to try:
- Use 'jar tf' (or something similar that will show you the contents of the jar file) to confirm that 'org.labkey.compbiostudy.dataLayer.baseClasses.DBHelper' is actually in the jar file in the build/deploy/modules/<first module> directory
- If you have a deployment created from your 17.1 LabKey, compare the build/deploy/modules/<first module> and build/deploy/modules/<second module> directories from that deployment with the one from 17.2
Let us know what that reveals, if anything.
Susan |
| |
| Matt V responded: |
2017-10-05 10:31 |
Hey Susan,
Ran the jar commands and compared the results for 17.2 and 17.1. They actually look identical with the DBHelper.class included in the first module. |
| |
| Susan Hert responded: |
2017-10-05 10:54 |
Here's something you wouldn't normally want to do, and, given that the directories are identical, I don't have much hope that this will be result in anything different, but I wonder if you will get the same results if you swap in the 17.1 versions of the modules instead of the 17.2 versions. To do this, you would need to remove the following from the 17.2 deployment :
- build/deploy/modules/<first module>.module file
- build/deploy/modules/<first module> directory
- build/deploy/modules/<second module>.module file
- build/deploy/modules/<second module> directory
Then copy the <first module>.module and <second module>.module files from the 17.1 deployment into the build/deploy/modules directory. (When Tomcat restarts, it will explode each module to create their respective directories.) |
| |
| Matt V responded: |
2017-10-05 12:05 |
I tried following your instructions, leaving the .module files with the 17.1 naming scheme (e.g. CompBioStudy.module) as well as adding the suffix (e.g. CompBioStudy-17.2.module). All I did with tomcat was fire up the debugger in intelliJ, no building with Gradle.
The webpart isn't loading now, but the modules are visible and appear to be enabled. Not seeing any errors in intelliJ or the chrome dev tools (console and network tabs). |
| |
| Jon (LabKey DevOps) responded: |
2017-10-05 13:11 |
Hi Matt,
Is the webpart just blank, spinning and looking like it's trying to load something, or is it something else entirely?
Have you been able to pick up any activity in the debugger, like a console or network entry that might be showing an error?
Regards,
Jon |
| |
| Matt V responded: |
2017-10-05 15:03 |
Hi Jon,
It's not actually rendering at all. If I try to re-add the web part I do see a 302 error:
GET /labkey/project/Oregon%20Pancreatic%20Tumor%20Registry/addWebPart.view?pageId=Search&location=%21content&returnUrl=%2Flabkey%2Fproject%2FOregon%2520Pancreatic%2520Tumor%2520Registry%2Fbegin.view%3FpageId%3DSearch&name=Search+-+Main HTTP/1.1
That's it though. Nothing in intelliJ or the console.
This is just since I removed the 17.2 module from gradle and put the 17.1 ant version of the *.module in there. |
| |
| Susan Hert responded: |
2017-10-05 17:23 |
You may want to revert this swapping in of the 17.1 versions of the modules. I suggested it in the vain hope that it might produce some kind of "ah ha!", but it has not. It seems there must be some difference between the two versions given that the behavior is different, but I fear that this hacked up investigation may produce more questions than it answers.
We generally make a separate api jar for a module if another module depends on it (which is where the depProjectConfig: apiCompile comes from), but that is really a compile-time thing, not a run-time thing unless I'm forgetting something about the class loaders.
Susan |
| |
| Matt V responded: |
2017-10-06 11:09 |
Alright, problem resolved with Trey's help this morning! Boiled down to the error message being misleading.
The problem stemmed from a static block within the DBHelper class. It was trying to get some params from the ServletContext that were returning null. When that class was initialized Java pretty much exploded and threw the class not found error. Fixing that within xml files was the eventual resolution. That, and restructuring the class to better report errors in the future.
Many thanks for yours and everyone's help resolving this! |
| |