I took a quick look at your XML file. The most immediate problem seems to be a case-sensitivity problem with one of the module names. If you change "ehr" to "EHR" the folder type seems to load fine.

Adam

hi adam,

thanks for looking into it, but that's not quite what i see. i still get the error even after capitalization. i should add two things:

1. i originally created this folder is a text-based module called 'EHR_reporting'. I moved this file to 'ehr' and deleted the 'EHR_reporting' module. Would that influence anything?

2. it is possible that i created a folder of this folderType during development without remembering it, although i cant find it anywhere.

are there other steps i could take? does this error help?


here is the exact error:

ERROR ModuleLoader 2010-09-07 19:39:13,163 http-8080-Processor23 : Unable to register folder type Expt Workbook from module EHR. A folder type with this name has already been registered.
java.lang.IllegalStateException: Unable to register folder type Expt Workbook from module EHR. A folder type with this name has already been registered.
    at org.labkey.api.module.ModuleLoader.registerFolderType(ModuleLoader.java:1063)
    at org.labkey.api.module.FolderTypeResourceLoader.loadResources(FolderTypeResourceLoader.java:46)
    at org.labkey.api.module.ModuleLoader.ensureStartupComplete(ModuleLoader.java:690)
    at org.labkey.api.module.ModuleLoader.doFilter(ModuleLoader.java:599)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
    at org.labkey.api.security.AuthFilter.doFilter(AuthFilter.java:113)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:873)
    at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
    at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
    at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
    at java.lang.Thread.run(Thread.java:619)

Hi Ben,

Is it possible that you still have a copy of EHR_reporting somewhere on your system? Does it show up in the list of modules in the Admin Console? Or do you possibly have two different .folderType.xml files that have the same <name> in the XML, even though they have different file names?

Thanks,
Josh

Once I changed to "EHR" I had no errors at startup, so I suspect it's something on your machine. I'm not super familiar with this code, but it certainly looks like there's another module trying to register the folder type.

- Have you done a rebuild since refactoring the modules?
- If you disable the EHR folder type (rename it .tmp) can you create folders of this type?
- If you can debug in IntelliJ then putting a breakpoint on ModuleLoader.registerFolderType() should pinpoint who is registering this folder type.

Adam

hi guys,

To answer Josh:

1. EHR_reporting does not show up in the admin console
2. I searched the folder containing my checked out copy of the trunk and I only find one file called 'Expt Workbook.folderType.xml'

To answer Adam:

1. i just did a build, but get the same results
2. when i rename the XML file I cannot create folders of this type.
3. i put a breakpoint at ModuleLoader.java line 1061.

I set the breakpoint on the line that throws the error. The attached screenshot shows the folder it is about to load, and also shows that another one of the same name is registered. I'm not entirely sure how to interpret this though.

I should note that in the admin console module list I see both 'ehr' and 'EHR'. it's been this way for some time. could this have anything to do with it?

Maybe I am misunderstanding what Adam said about capitalization. I assumed you were referring to this line in the XML file:
<moduleName>EHR</moduleName>, which i changed from 'ehr' to 'EHR'. were you talking about somewhere else?

Yes, I was talking about 'ehr' vs. 'EHR' in the XML file. When I made that fix, everything started working.

The admin console clearly shows the problem: you have two EHR modules, one in D:\labkey_trunk\server\customModules and one in D:\labkey_trunk\build\deploy\modules. Delete whichever one is obsolete... I think it's the one in customModules. You should delete all other obsolete modules in there.

Your breakpoint where the error is reported shows the "good module" attempting to register. If you put a breakpoint on the call to ModuleLoader.registerFolderType() at the bottom of FolderTypeResourceLoader you'll be able to monitor every registration, including the "bad module". This probably isn't necessary since the admin console shows where the "bad module" lives.

Adam

i understand what you're saying, but I believe that creates other problems. historically the non-java EHR module and java-EHR module were separate folders in /server/customModules/. here's how my machine is configured:

I checked out a copy of labkey from svn to D:\labkey_trunk\. This is what I used to build. My external modules folder is set to: d:\labkey_trunk\server\customModules. Using this approach, I can make changes in the files and any changes will be live in the local instance of labkey i'm running. If I do what you suggest, I dont think that live development will work, since /build/... is going to have a snapshot of them. I also probably dont want to actually develop using the files in /build/ since I assume those can get overwritten easily.

can the java and non-java modules be made to better co-exist? otherwise i think we might need to re-split the java and non-java parts.

Hi Ben,

In development mode (-DdevMode=true), the server should automatically grab the latest copy of non-Java resources from the source tree, even for modules that are built and deployed into the ./build/deploy/modules directory. It's certainly possible that some specific types of resources don't work this way, but in general they do and it's a scenario we want to make convenient for developers.

Please give it a try and let us know if you run into problems.

Thanks,
Josh

i do have -DdevMode=true. we're 50% of the way there:

as expected, by removing -Dlabkey.externalModulesDir="D:\labkey\server\customModules", i eliminate the redundant loading of the folder XML. I can also see live changes to text-based files in the EHR module, as expected from -DdevMode.

The problem is that other text-based modules in \server\customModules are not being loaded since removing the externalModulesDir line. any way to get these to load w/o redundantly loading the EHR code? is there some sort of flag i may inadvertently have in the EHR module that is causing it to load as a file-based module? can i add some flag to prevent it from being loaded as one?

i have no explanation at all for this, but something about the act of adding/removing externalModulesDir from the tomcat config and restarting tomcat a few times seems to have things working properly. i have externalModulesDir point to customModules of the checked out project. This is loading all the text-based modules, but is not double-loading the folderType XML file.

i did notice that when I removed the externalModulesDir param from the tomcat config, some files were cleaned from the build folder when i started tomcat. perhaps there was something in there not getting removed properly from all the earlier moving of files between the modules. i did a clean / build yesterday, but that did not seem to fix whatever was going on.

sorry for the all the posts, but things seem to be working correctly now.

Hi Ben,

Glad to hear it's working. Let us know if the issue resurfaces and we can look closer at this particular scenario.

Thanks,
Josh