Hi,
I think I may have good news.
Our problem with Spring and multinode was that GeoNetwork messed
things up mixing beans from one node to the other, making it
impossible to autowire beans. I know we have been taking a look at
this and dragging the context from one service to another crying for a
good autowiring functionality.
Ok, my rubber duck council[0] just told me to use a different servlet
for each node. This complicates just a bit the configuration (you have
to replicate spring-servlet.xml file, for example), but on a first
glance, it appears to work.
So my question is very simple: has anyone already tried this approach
and abandoned it for any good reason? Or is it just that we are too
focus on the huge frankensteined architecture that we didn't even
think of it? Does Ockham[1] win this time?
I don't want to waste time on testing this if somebody has already tried it.
Regards,
María.
[0] https://en.wikipedia.org/wiki/Rubber_duck_debugging
https://pbs.twimg.com/media/CWQRly4WUAA4BY0.jpg
[1] https://en.wikipedia.org/wiki/Occam's_razor
--
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
On Tue, Dec 15, 2015 at 10:00 AM, Francois Prunayre
<fx.prunayre@anonymised.com> wrote:
With this approach, it will be more or less the same as duplicating the WAR
? Multinode was also the idea of being able to share part of the application
consuming resources - eg. ThesaurusManager using Sesame loading all
thesaurus in memory - if you've 20Mo of thesaurs and 250 nodes on a server,
that makes quite some memory required.
But then all thesaurus are shared between all instances? Is that a good idea?
In any case, we can try an approach like this one:
http://stackoverflow.com/questions/10339174/how-do-you-share-spring-beans-between-different-spring-contexts
http://stackoverflow.com/questions/5132604/why-use-spring-applicationcontext-hierarchies
https://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
And have different spring contexts for each node and a parent context
with all the shared nodes.
Maybe it is just me because I hate having to drag the context
everywhere, it makes the code very dirty. But I prefer to have Spring
on friendly terms and being able to use it.
On Tue, Dec 15, 2015 at 10:11 AM, María Arias de Reyna
<delawen@anonymised.com> wrote:
On Tue, Dec 15, 2015 at 10:00 AM, Francois Prunayre
<fx.prunayre@anonymised.com> wrote:
With this approach, it will be more or less the same as duplicating the WAR
? Multinode was also the idea of being able to share part of the application
consuming resources - eg. ThesaurusManager using Sesame loading all
thesaurus in memory - if you've 20Mo of thesaurs and 250 nodes on a server,
that makes quite some memory required.
But then all thesaurus are shared between all instances? Is that a good idea?
In any case, we can try an approach like this one:
http://stackoverflow.com/questions/10339174/how-do-you-share-spring-beans-between-different-spring-contexts
http://stackoverflow.com/questions/5132604/why-use-spring-applicationcontext-hierarchies
https://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
And have different spring contexts for each node and a parent context
with all the shared nodes.
Maybe it is just me because I hate having to drag the context
everywhere, it makes the code very dirty. But I prefer to have Spring
on friendly terms and being able to use it.
The parent-context approach is something beyond the scope of what I am
doing right now, so probably I will just make a fix on the current
workflow stuff and use the drag-context approach. And I know that you
are busy today with the 3.0.3 release. So I will not force a decision
soon, just think about it.
But I warn you: I won't let this sink until we have a good solution 
2015-12-15 10:11 GMT+01:00 María Arias de Reyna <delawen@anonymised.com>:
On Tue, Dec 15, 2015 at 10:00 AM, Francois Prunayre
<fx.prunayre@anonymised.com> wrote:
>
> With this approach, it will be more or less the same as duplicating the
WAR
> ? Multinode was also the idea of being able to share part of the
application
> consuming resources - eg. ThesaurusManager using Sesame loading all
> thesaurus in memory - if you've 20Mo of thesaurs and 250 nodes on a
server,
> that makes quite some memory required.
But then all thesaurus are shared between all instances? Is that a good
idea?
GEMET or INSPIRE themes or list of countries, ... are usually all the same,
and you can still disable a thesaurus from the admin if a node does not
want to use it.
Francois
In any case, we can try an approach like this one:
http://stackoverflow.com/questions/10339174/how-do-you-share-spring-beans-between-different-spring-contexts
http://stackoverflow.com/questions/5132604/why-use-spring-applicationcontext-hierarchies
https://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
And have different spring contexts for each node and a parent context
with all the shared nodes.
Maybe it is just me because I hate having to drag the context
everywhere, it makes the code very dirty. But I prefer to have Spring
on friendly terms and being able to use it.
