chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Streit <mcs...@gmail.com>
Subject Re: in memory server with dynamic WS deployment
Date Fri, 05 Oct 2012 14:17:35 GMT
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 <cdan@savatech.ro> 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.
>



*
*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message