Hi Jeff,
The Binding WAR contains a dummy configuration with a dummy
implementation that only provides repository infos.
The idea was to provide a more or less working starting point for
server developers.
It turned out that this dummy configuration can create problems in some
containers. With OpenCMIS 0.8.0 starting the Binding WAR will fail with
an error message because it cannot find a service factory class. That
should fix the container issue and should avoid confusion.
Florian
I was working with the Shindig and Rave guys at OSCON today. We were
getting an OpenCMIS InMemory server set up on their machines and then
creating a basic CMIS gadget. Accidentally, they downloaded:
http://www.apache.org/dyn/closer.cgi/chemistry/opencmis/0.7.0/chemistry-opencmis-server-bindings-0.7.0.war
Instead of:
http://www.apache.org/dyn/closer.cgi/chemistry/opencmis/0.7.0/chemistry-opencmis-dist-0.7.0-server-webapps.tar.gz
When they started up the "server bindings WAR", the server was
reporting itself as OpenCMIS version 1.0 in productVersion. But when
you run the InMemory WAR included in the server webapps tarball you
get 0.7.0, as I'd expect.
A couple of other differences:
- In the server bindings WAR, the InMemory repo starts up with a
repository ID of "dummy-rep" instead of "A1".
- The browser binding's rootFolderUrl returns not supported when
invoked whereas the browser binding root URL in the server webapps
tar
ball works fine.
Is this a problem with our packaging/release or is it working as
designed?
Jeff
