The server component can be configured through its Spring application context configuration file
kosmos-services-servlet.xml
. (Please note that former versions were configurable partly through their
web.xml
, but after introducing the pluggable
cache store mechanism, all configuration was moved to the Spring
XML.) It's absolutely straightforward to modify it, but
please note that the configuration changes might require
reloading the servlet!
Here is some basic help for better understanding of the kosmos-services-servlet.xml
:
Each service is implemented by a POJO that is exposed as web service by a Spring-based Hessian proxy class. Consequently there is one section like this per service:
<!-- CC service --> <bean id="ccService" class="hu.midori.kosmos.server.cc.CcServiceImpl"/> <property name="store" ref""webdavCachedDataStore"/> </bean> <bean name="/cc-service" class="org.springframework.remoting.caucho.HessianServiceExporter"> <property name="service" ref="ccService"/> <property name="serviceInterface" value="hu.midori.kosmos.protocol.CcService"/> </bean>
You can activate and deactivate the services by adding or deleting these sections, depending which portlets you're going to use. In the default configuration, all the services are activated and unless there is a special reason to remove them, it's better not to touch these sections. There is hardly any performance penalty or security problem even if you have unused, but active services.
There is one required property for the services: this is called
store
and it's a reference to the cache store
to use. See next section for more details.
The services can generate and save cached data, mostly images that are later used by the portlets view tier. There is a simple, but flexible store mechanism built into Kosmos. However this is a "pluggable" mechanism, by default, there is only one implementation shipped with Kosmos: a WebDAV-based cache store. (In the very beginning, using WebDAV for this purpose was a requirement, not an option, but the poor quality of the WebDAV client libraries and servers motivated adding an extra level of abstraction to ensure that with some minimal work, any other web-based store can be used here.)
The cache stores are implemented as POJOs, too. They can have different
properties depending on the implementation, we discuss only
WebdavCachedDataStore
here:
<!-- WebDAV cached data store --> <bean id="webdavCachedDataStore" class="hu.midori.kosmos.server.WebdavCachedDataStore"> <property name="webdavUrl" value="http://localhost:8080/slide/files"/><!-- Both HTTP and HTTPS protocol can be used here. --> <property name="webdavUser" value=""/> <property name="webdavPassword" value=""/> <!-- This URL will be used as base URL for the generated images. If you don't specify anything here, the value of "webdavUrl" will be used. Uncomment this, if you want to override that. <property name="clientUrl" value="http://myserver/my-webdav/kosmos-images"/> --> </bean>
The URL is required, but you can leave the user and password
empty if your WebDAV is configured to serve
unauthenticated requests, too. In the URL you can use
both HTTP and HTTPS protocols. The
clientUrl
parameter makes it possible to
override the URLs generated for the clients: you can store the images as
https://secure.mydomain.com/mywebdav
,
but access them as http://public.mydomain.com/webdav
if your network environment is configured to match this.
It's possible (and relatively easy) to do more complicated changes (like using separate or even inhomogenous cache stores per service, using more than one instance of the same service, etc.), but please make sure that you know what you do. It's recommended to study the related sections of the Spring Framework documentation, too.
Please take a look at the sample configuration files shipped in the distributed package.