Best place for common applications services

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

Suppose you want to introduce a new service common to several applications, what would be the best place?

Naïvely, I choose commonext. Wrong choice, because commonext is currently loaded after all other applications component. So I got a classloader issue 
at StandardJavaEngine.java[97] (in my case the service would be shared at least by order and accounting).

I still think it should be the best (intuitive) place for a common applications service. But it can't be without, I guess, breaking the current state 
for other services. I say I guess because for instance loading commonext as 1st component does not seem to break the *SystemInfo* service. But I 
believe Hans put it there with this comment "common component used by most other components last because it uses info from most components" for good 
reasons.

There are of course other options:
1) Put the common java service code in the 1st loaded applications component which uses it (not tried, should work, not satisfying because of 
components dependency)
2) Put the common java service code in own hot-deploy component (works, but can't be contributed as is)
3) Like some existing services in framework common component (not tried, should work, not satisfying because of components dependency)

So few questions:

@Hans, did you encounter issues which made you placing commonext at the bottom of the applications component-load.xml file? Else I'd prefer to load it 
as 1st component. The reason is if it's common to other components then it should be available in 1st place and should not depend on them.

@David, @Jacopo,
Why are services like those contained in
CdyneServices.java
CommonDimensionServices.java
in framework common component?Are they dependent on something which makes them land there? Are there not better places for them, like commonext and bi 
respectively?

Note: I did not find other classes in framework common component which would make me asking the same question, maybe there are... Ha @Hans, 
UrlServletHelper.java is also concerned because it relies on content and marketing components. Ok not enough time to deal with in depth :/ ...

Thanks for your answers and opinions

Jacques