Skip to content

Frascati in Nuxeo Alternatives

Jump to bottom Edit New page
mdutoo edited this page Nov 10, 2011 · 24 revisions

Needs & requirements :

  • R1. required to embed in EasySOA Core / Nuxeo "Light" proxies (SLA, monitoring, Light proxy factory), as well as deploying them standalone. Because a lot of JVMs are already started up right now in the release, embedding it in Nuxeo will make it faster.
  • R2. integration has to be maintainable and testable
  • R3. should help solve classloader & visibility problems, between Nuxeo & FraSCAti, but also between various business developments
  • ex. in Smart Travel demo where all services and mockups share the same java package and some classes (generated by JAXWS) have the same name and therefore conflict.

Alternative solutions :

  • S1. OSGi everywhere : nuxeo, frascati, frascati-based apps
  • S2. OSGi embedded in Nuxeo (sfermigier) : start a Felix Nuxeo, deploy FraSCAti bundles in it, and write an adapter to access them.
  • S3. FraSCAti embedded in Nuxeo (pmerle)
  • S4. Use a single FraSCAti for all needs, and interact with it in e.g. REST & FraSCAti introspection.

Concrete questions / problems to solve :

P1 would that solve lib conflict issues between Nuxeo & FraSCAti ? And how much conflicts is there ?

A simple script shows there are 90 frascati libs in nuxeo and 57 nuxeo libs in frascati. However, no global version compatibility analysis has been done yet ; versions seem to be mostly different which is usually bad, though sometimes not (ex. different major versions of Jetty used with different packages prevent incompatibility)

Possible solutions are :

  • solving conflicts "by hand". For instance, Nuxeo libs have to be used by FraSCAti instead of its own OR VICE VERSA and maven pom to be adapted with the right exclusions. However, there is no guarantee there exists a set of lib versions that is conflict-free, and (according to my own experience) it has a prohibitive maintenance cost.
  • separate classloaders, that can be :
  • osgi,
  • "hand-crafted",
  • embedded OSGi runtime,
  • webapp / war or other appserver-controlled classloader
  • SCA applications i.e. FraSCAti.

P2 would it be easy to add further FraSCAti plugins as dependencies in it at will ?

Possible solutions are : only separate classloaders (see above)

P3 And between various business developments ?

Possible solutions are :

  • separate classloaders (see above),
  • naming app classes with EasySOA-managed unique identifiers (using prefixes...)

P4 Can it be easily tested ?

And in the same conditions as it is deployed.

That means using (Nuxeo- or OSGi-provided) tools or enriching them.

Evaluation :

S1 OSGi everywhere

OSGi is not a miracle answer (since it's costlier, needs refactoring & good practices), Nuxeo is not yet really OSGi compliant. Underway at INRIA, for now though still uses a single shared classloader (see below). So it's rather a long term solution.

A pragmatic alternatice is "coarse-grained" OSGi, i.e. using a limited number of big bundles :

S2 Embedded in OSGi runtime

  • P1 : I guess yes ?
  • P2 : yes
  • P3 : depends on whether FraSCAti apps classloader isolation would still be valid, TODO pmerle ?
  • P4 : Nuxeo test framework would have to be enriched to handle startup and configuration of the embedded OSGi runtime.

S3 Embedded FraSCAti

NB. there may be

  • P1 : not really (Nuxeo libs have to be used by FraSCAti instead of its own OR VICE VERSA and maven pom to be adapted with the right exclusions), save with separate classloaders : hand-crafted or appserver. SCA application is not very interesting because it would have been a single big one, including business applications, since otherwise generic code couldn't be seen from business code. See below "conflicts".
  • P2 : not really (possible new lib conflicts have to be handled), save with separate classloaders (hand-crafted, appserver). For some tests it's OK (SCA parsing in Nuxeo), for others not (HTTP monitoring in Nuxeo, seems to disturb Nuxeo runtime core).
  • P3 : I guess no, save if app classes are named with EasySOA-managed unique identifiers (using prefixes...) or with separate classloaders (appserver, SCA applications)
  • P4 : Test framework has to be enriched to setup separate classloader.

Conflicts encountered between FraSCAti and Nuxeo up to now (FraSCAti / Nuxeo) :

  • org.eclipse.jdt.core (3.3.0.771 / 3.1.1-NXP-4284)
  • Solved at test time by using only FraSCAti's by pmerle in easysoa-registry-frascati-wrapper with minimal dependencies, see #21. NB. If has to be resolved at runtime, for jetty apply NXP-4284 on FraSCAti's.
  • Then refactored OK to easysoa-registry-frascati with easysoa core and common FraSCAti bindings as dependencies and working SCA import using FraSCAti code, see #28 Discovery by parsing SCA composite using FraSCAti parser
  • A web test deployment (with Nuxeo webapp, WebEngine, automation...) in easysoa-registry-rest-frascati seems also OK (though not finished)
  • however starting HTTP monitoring in Nuxeo brought problems (incomplete study, seems to disturb the Nuxeo core runtime ?!)
  • Distribution test works and FraSCAti-based SCA import works, when fully deployed. This means copying FraSCAti libraries, see again at the end of #28, the only problem stemming from P3. There is no conflict between both jdt.core libraries, because they reside in different classloaders, from root to leaf : jdk ext - tomcat bootstrap - lib/ (with FraSCAti) - nxserver/lib, nxserver/bundles (Nuxeo) and nxserver/plugins (EasySOA)
  • TODO NOK test environment (trying web explorer, start ; however import until generation OK) because of single classloader
  • TODO NOK distribution web explorer start LinkageError, because of twice the same JAXR API jar. Removing one of them (Nuxeo's) brings about an HTTP port conflict problem. See TODO web explorer archi issues
  • TODO NOK distribution pojo start NullPointerException because of JDT conflict. Maybe a strange classpath in Juliac, ex. FileSystem.classpathNames regroups ALL jars from all dirs together (maybe solved by latest one ?) and CompileSupportImpl.classpath is .:/data/home/jguillemotte/EasySOA-Workspace/easysoa/easysoa-distribution/easysoa/serviceRegistry/nxserver/lib:/data/home/jguillemotte/EasySOA-Workspace/easysoa/easysoa-distribution/easysoa/serviceRegistry/bin/bootstrap.jar. => pmerle : yes it's this problem and it's been solved but not yet brought in FraSCAti

Other (non FraSCAti related) conflicts in Nuxeo :

  • when using Jersey as client library with FraSCAti tests in the httpmonitoring proxy, trying to put Nuxeo in (embedded) would make its use as client fail because of API differences (Nuxeo version is quite older). Solved by not using Jersey as a client library but Apache HTTP Client instead.

S4 Remote FraSCAti

  • P1 : yes,
  • P2 : yes,
  • P3 : yes,
  • P4 : no
Add a custom footer
Add a custom sidebar
Clone this wiki locally