Hi
On 17.11.2011, at 11:57, Enrico Daga wrote:
> Hi,
> it seems to me that a similar discussion have been already taken in
> the list, but I can't find it.
>
It was about the time of the Paris Workshop when Szaby worked on the
Stanbol-VIE stuff.
> My problem is related to STANBOL-378, which started as a problem with
> a disappeared function but know it looks to me a more generic issue.
>
> I have deployed the integrity-check demo within a full launcher +
> reasoners, and the demo - which worked since some time ago - raised
> problems with javascript.
>
> I see now a lot of javascript libs embedded in the page, some of them
> are duplications of the same library, in one case they are the same
> library but with different version.
[..]
> The problem here is that the loading order is **out of control**,
> because is demanded to the JAX-RS resource initialization.
> If I restart bundle , for example, and reload the page, I see some
> differences:
[..]
> I don't know if this order is deterministic or not, but I am sure that
> this makes the whole Stanbol UI potentially unstable.
>
This is mainly because ScriptResource does not implement comparable and
Collections.sort(List<ScriptResource>) is used in the JerseyEndpoint.
Sorting will therefore be randomly.
> As immediate workaround I suggest to **do not** share js libraries
> between different JAX-RS resources, and maybe create a /static/commons
> path where to put shared js code (but not embedding it automatically)
>
> Any other idea?
>
Maybe using maps {lib-name} -> {ScriptResource} instead of this list.
We could than define a default map (available to all WebFragments) and
WebFragments could provide there own map. The key could be used to override
libs from the default. Using a NULL as value would deactivate a lib and using a
{ScriptResource} as value would allow to use e.g. a different version (e.g.
"jquery-1.5.1.js" instead of "jquery-1.4.2.js").
WDYT
Rupert
> Enrico
>
> --
> Enrico Daga
>
> --
> http://www.enridaga.net
> skype: enri-pan
