Not sure what your specific use case is (so pardon any assumptions) ...but just a couple of thoughts:
1) To Florian's point, I would not think one would want to "tamper" with the Chemistry In-memory WAR ... configuration files, endpoint descriptors, etc since it is all self-contained (hence the JAX-WS RI JAR files, etc). You drop it in /webapps under Tomcat and it just "goes". 2) Since you have your *own *services that you want to develop anyway, (and you mentioned this is POC work)...are you not going to want those custom services in their own deployable WAR ... specifically for your services when you eventually cut over to a more robust CMIS server implementation (beyond the in-memory one being used for testing and POC work). I realize those service endpoints will be running on a different context-root (but can be in the same container). 3) If they are in their own deployment unit (WAR), and you want to use Apache CXF (which, is far better than Axis2 IMO, with a very active/helpful development community - similar to this one for Chemistry), you could include the required set of CXF component JAR files in the /WEB-INF/lib of the WAR (similar to how Chemistry carries the JAX-WS RI). You could take advantage of the all the dynamic stuff that CXF provides since you're isolated in your own WAR and not infringing on Chemistry's implementation. I know we have done similar things where we wanted to use a specific JAX-WS implementation (CXF or JAX-WS RI/Metro) and were running on a WAS 7 app server. You have to do some classloader setting gymnastics especially for WAS 7 since they unfortunately bury Axis2 into their own runtime stack and the WAS classloader is a complex "thing" ( I could use a more colorful word for it ). If you're running on a Tomcat instance or lighter-weight container - it's immensely easier since you have way more control. FWIW - we used the Chemistry "fileshare" implementation for some POC work - worked great OOTB and then switched the POC as it expanded to use things things like Alfresco 4 (community edition) and Sharepoint (and so far AF4 has shown to be more CMIS-compliant especially with the CMIS SQL). As I noted - just a few thoughts. Mark On Fri, Oct 5, 2012 at 4:37 AM, Dan Corneanu <[email protected]> wrote: > On 9/28/2012 11:37 AM, Florian Müller wrote: > > What kind of dynamic do you need? It implements an industry standard > > and everything is fixed by the standard. There is nothing you can add > > without violating the standard. > I want to deploy some custom/higher level SOAP Services alongside the > CMIS services. The CMIS API/Services will stay the same. Is this against > the standard? I do not want to extend/modify the CMIS interface. The > extra services will be in a different name space etc. > > Best regards, > Dan. > * *
