Embedded Tomcat support for custom webapp resources

[labkey-tchad]

Rationale

A more generic solution for adding Resources to the webapp.
labkey.xml could have arbitrary <Resource> elements. This adds similar capability to application.properties.

This JMS resource from labkey.xml:

<Resource name="jms/ConnectionFactory" auth="Container"
        type="org.apache.activemq.ActiveMQConnectionFactory"
        factory="org.apache.activemq.jndi.JNDIReferenceFactory"
        description="JMS Connection Factory"
        brokerURL="vm://localhost?broker.persistent=false&amp;broker.useJmx=false"
        brokerName="LocalActiveMQBroker"/>

Can be represented like this in application.properties:

context.resources.jms.name=jms/ConnectionFactory
context.resources.jms.type=org.apache.activemq.ActiveMQConnectionFactory
context.resources.jms.factory=org.apache.activemq.jndi.JNDIReferenceFactory
context.resources.jms.description=JMS Connection Factory
context.resources.jms.brokerURL=vm://localhost?broker.persistent=false&broker.useJmx=false
context.resources.jms.brokerName=LocalActiveMQBroker

The jms in the property names is required to link related resource properties together but its exact text is unimportant.

Related Pull Requests

• Support all labkey.xml/ROOT.xml settings via application.properties #680

Changes

• Add support for custom webapp resources

[labkey-jeckels]

This looks great. I think it would let us rip out the jms. and ldap. examples from application.properties and the corresponding Java code in LabKeyServer, correct? The only downside is that it doesn't let us set default values for some of the properties, but we didn't have that in labkey.xml so that's not currently the expectation.

[labkey-jeckels]

This also gives me an idea of how we can make the DataSource and extra webapp config a little cleaner...

[labkey-jeckels]

See my one recommendation. After we merge the Tomcat 10 branch I'll rip out my more hard-coded handling for JMS and LDAP config.

[labkey-jeckels]

Some other config errors are fatal on startup, throwing an exception. I think that's probably the right direction to lean unless there's a good reason to be tolerant of an invalid config.