RE: Ignite equivalent of @GridUserResource

2018-05-22 Thread Stanislav Lukyanov
Well, with such a big leap between versions I’d say whatever works is good :)

Being nervous about the jar hell is always wise.
Going through the dependencies is probably the most straightforward option, 
unfortunately.
You could try to reduce the number of Ignite modules you’re using - optional 
ones are not picked up by default 
and ignite-core has almost no dependencies.
Or you could build your servers as regular Java applications, with a Main class 
instead of ignite.sh runner.
Then you’ll declare the Ignite modules you need as dependencies, and with some 
Maven kung-fu you should be able
to identify (and hopefully fix) conflicts at build-time.

Thanks,
Stan

From: chuston
Sent: 18 мая 2018 г. 4:04
To: user@ignite.apache.org
Subject: Re: Ignite equivalent of @GridUserResource

I'm also reviving a mothballed GridGain system that used a @GridUserResource
- moving from Java 6/GridGain 3 to Java 1.8 / Ignite 2.4.0+ 

To replace it, I'm doing the following: 
- Use a LifeCycleBean that populates the nodeLocalMap before startup. 
   - the objects placed in the nodeLocalMap are factories for accessing
other reference objects needed by the jobs (Company, Document, History
instances) 
- Copy the jar with the LifeCycleBean and all of it's dependencies into a
subdirectory of ${IGNITE_HOME}/lib 
   - Since the factories use web services, databases, etc - there are a lot
of dependencies 
- Side note: I also have a partitioned cache warming step so need the cache
key-value classes and loader dependencies too 

Two questions: 
1) Is there a better way to do it? 
2) I'm nervous that if I just do something like "mvn
dependency:copy-dependencies" that I will be putting jars into the lib
directory that contain classes used by ignite and inviting weird class cast
exceptions / class loader issues. I'm not at all excited by trying to sort
through which jars I depend on but are already present in the ignite
distribution / optional modules etc. Is there a magic reason not to worry
about this? Is there a better way to approach it? 

Thanks, 
-- Chris 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/



Re: Ignite equivalent of @GridUserResource

2018-05-17 Thread chuston
I'm also reviving a mothballed GridGain system that used a @GridUserResource
- moving from Java 6/GridGain 3 to Java 1.8 / Ignite 2.4.0+ 

To replace it, I'm doing the following: 
- Use a LifeCycleBean that populates the nodeLocalMap before startup. 
   - the objects placed in the nodeLocalMap are factories for accessing
other reference objects needed by the jobs (Company, Document, History
instances) 
- Copy the jar with the LifeCycleBean and all of it's dependencies into a
subdirectory of ${IGNITE_HOME}/lib 
   - Since the factories use web services, databases, etc - there are a lot
of dependencies 
- Side note: I also have a partitioned cache warming step so need the cache
key-value classes and loader dependencies too 

Two questions: 
1) Is there a better way to do it? 
2) I'm nervous that if I just do something like "mvn
dependency:copy-dependencies" that I will be putting jars into the lib
directory that contain classes used by ignite and inviting weird class cast
exceptions / class loader issues. I'm not at all excited by trying to sort
through which jars I depend on but are already present in the ignite
distribution / optional modules etc. Is there a magic reason not to worry
about this? Is there a better way to approach it? 

Thanks, 
-- Chris 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/