Wishlist

Custom ClassLoaders for Modules

OpenCms should provide its own ClassLoader for each module.

• The Module ClassLoader is instantiated along with the module and used to load classes, classpath resources and libraries contained in the module directly from VFS.
• The classpath of a Module ClassLoader contains
  • /system/modules/<modulename>/classes/
  • /system/modules/<modulename>/lib/*.jar
• Module dependencies make up a Module ClassLoader hierarchy. If module B depends on module A, the Module ClassLoader of B has the Module ClassLoader of A as its parent, thereby making A's classpath available to B.
• The Module ClassLoader of a module which does not depend on a different module has the standard Webapp ClassLoader as its parent.
• When a class should be loaded, the Module ClassLoader first looks into the module classpath. If it does not find the class there it delegates class loading to its parent.
• Each time OpenCms detects that a file on the Module ClassLoader classpath changes, the Module ClassLoader is thrown away and a new instance is created.

Benefits:

• No need to export files from the VFS to WEB-INF/lib and WEB-INF/classes.
• It is no longer required to reload OpenCms for each change to a module classpath file.
• Ability to use different and incompatible versions of libraries in different modules.

Open Questions: How would the Module ClassLoader perform JSP loading?

manifest.xml

The file manifest.xml contains information about a module. However, as of version 6.2.2, there is no way to create such a file outside of OpenCms which is an obstacle for the creation of modules for OpenCms.

If a ZIP archive which contains module files does not have a manifest.xml OpenCms refuses to import the module. This makes module development hard. You need to use the synchonization feature which is not appropriate in all cases because it cannot distinguish system files and files added by a module (e.g. the icons in /system/workplace/resources/filetypes) and thus can lead to inadvertent deletion of system files if used without enough experience.

There is currently only one way to create a valid manifest for a module: Make all changes in the OpenCms frontend and export the module. There should be a way to create a valid module ZIP archive outside and without the help of OpenCms.

Wishes:

• The XML Schema Definition of the manifest file format of should be made public
• There should be a small tool independent of OpenCms with an API to create and maintain manifest files for modules being developed outside of OpenCms.

JSR 170

It would be good for OpenCms if it would implement the JSR 170. In the spirit of openness and interoperability, this would be a major boon.

More information on JSR170

The JSR on the JCP site

Directory handling consistent with Apache

Say you have web page /news/index.html. You can access that page with several URLS:

1. http://www.mysite.com/news/index.html
2. http://www.mysite.com/news/
3. http://www.mysite.com/news

(note 2 and 3 are subtly different, but they are different).

In case 3 Apache automatically redirects to case 2. This is correct behaviour for several reasons:

• If you use traffic analysis software (eg Google Analytics) case 2 and case 3 are treated as different pages, thus confusing your reports.
• If for some reason you have relative links in the page they won't work as expected (the browser will think you are looking at a file called "news"

at the root level and consequently all relative paths will be relative to root)

• If you use Google Maps which has a directory specific key it fails if you access the page using case 3 (again because the browser thinks it's a file

at root level)

Support for XML Schema Inheritance

It turns out, that quite often one ends up reusing a schema for xml content that is only slightly different each time. Especially when using the OpenCmsHtml datatype one's frequently actually only changing the styles to be used (css, styles xml).

In this case the use of XML schema inheritance as stated in the spec would be really useful (see also W3C XML Schema Primer, IBM article on flexible and extensible XML schemas). Do you think you will be able to offer such a feature in upcoming versions of opencms?

Here is an example of a standards-compliant xml content schema that would be cool if it worked:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:include schemaLocation="opencms://opencms-xmlcontent.xsd"/>
<xsd:include schemaLocation="opencms://system/modules/org.opencms.frontend.templateone.form/schemas/form.xsd"/>
 
<xsd:element name="MyOnlineForms" type="OpenCmsMyOnlineForms"/>
 
<xsd:complexType name="OpenCmsMyOnlineForms">
  <xsd:sequence>
	<xsd:element name="MyOnlineForm" type="OpenCmsMyOnlineForm" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
 
<xsd:complexType name="OpenCmsMyOnlineForm">
  <xsd:complexContent>
	<xsd:extension base="OpenCmsOnlineForm">
		<xsd:sequence>
			<xsd:element name="LabelForSubmitButton" type="OpenCmsString" />
		</xsd:sequence>
	</xsd:extension>
  </xsd:complexContent>
</xsd:complexType>
 
<xsd:annotation>
  <xsd:appinfo>
	<resourcebundle name="my.module.workplace"/>
	<layouts>
	<layout element="FormText" widget="HtmlWidget" 
	  configuration="source,link,anchor,image,table,css:/system/modules/my.module/resources/mystyle.css,
	  stylesxml:/system/modules/my.module/resources/mystyle.css_style.xml" />
	<layout element="FormConfirmation" widget="HtmlWidget" 
	  configuration="source,link,anchor,image,table,css:/system/modules/my.module/resources/mystyle.css,
	  stylesxml:/system/modules/my.module/resources/mystyle.css_style.xml" />
	</layouts>
  </xsd:appinfo>
</xsd:annotation>  
</xsd:schema>