easysoa/EasySOA — Issue #82: EasySOA-Registry-Core code cleanup
Author: tiry
Created: 2011-12-28 14:11:11+00:00
State: open

I did a very quick review of the code and tested the app inside Nuxeo 5.4.2.

Here is some feedback on things that could be improved.

## Seam beans

I would clearly move the seam beans in a separated module.

The registry-web module seems to be a nice candiate for hosting them.

This is not strictly required (it does work with current layout), but this makes sense in terms of layer separation and this would allow to use Nuxeo IDE with full Hot Reload of the Seam part.

## ContentTemplate

Nuxeo Platform has an extension point to define what the initial Content Layout must look like.

From my understanding what you have in DomainInit / EasySOAInitComponent could easily move to a content template.

[See Content Template Extension Point] (href="http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionPoint/org.nuxeo.ecm.platform.content.template.service.ContentTemplateService--factoryBinding)

As for the default users, you can contribute them via a CSV file
=> we can see this together if needed

NB : In addition of avoiding uneeded infrastructure code, it would also allow to leverage existing code that already handle TX issues at startup that may be diffrerent depending on the target Database : so this would make the current code shorter and more resilient

## Sync Listeners

There are several sync listeners.

One of them uses HttpFile to fetch a WSDL and parse it.

This is very dangerous to do it synchronously and this won't work if the server if behing a proxy.

I would say that it is probably better to move it in async and use an Http pool that use Nuxeo http proxy config, but this is an improvement and not an urgent matter.

NB : for that I may have some small work on the Nuxeo side to make available the http pool as a service, but once we are aligned on 5.6 this should be a matter of hours.

## JSF WebPart

EasySOA contains overides of the default templates.

Even if we technically allow that, this not the best option, at least in terms of upgrade.

We should be able to contribute all specific display using actions and widgets and remove all overrides.

For the EasySOA submenu, may be it would make sense to make it a real tab and use the AdminCenter/Home structure so that you can add all the required EasySOA specific config screens.

=> to be discussed (and done) during a workshop between Marwan and me

## LifeCycle

I see several fields in your XSDs that really looks like lifecycle state.

I don't see why we can not use the native LifeCycle system from Nuxeo.

If needed you can see example [here](http://doc.nuxeo.com/display/Studio/Define+DocumentationItem+content+life+cycle) and a short introduction [here](http://doc.nuxeo.com/display/NXDOC/About+the+content+repository#Aboutthecontentrepository-LifeCycle).

## API names

Main API for changing your services is notifyXXX.

For me this sounds like an event driven (async) API, but it's not.

In addition the Map<String,String> is good for an event driven API, but not so good if you want a real API (no type safety and loose coupeling).

=> am I missing something ?