Well, TomEE is using System.properties to store its IVmContext… I can’t make 
change all open source projects on this point, even if I’m agree with you.

I have only one Ignite instance started in this case. This is really strange.

From: Matt Hoffman [mailto:m...@mhoffman.org]
Sent: mercredi 13 janvier 2016 15:31
To: user@ignite.apache.org
Subject: Re: Ignite "bugs" ?

Using System.properties() to store non-strings is really poor behavior. It 
violates the contract of the System.setProperty and System.getProperty, as well 
as the contract of the Properties object itself, from right at the top of the 
javadoc:  "Each key and its corresponding value in the property list is a 
string."
I've hit something like that in Hibernate before, years ago; I'm surprised they 
haven't fixed it yet. It's a long-standing bug in Hibernate. Not to say Ignite 
shouldn't have a workaround for badly-behaved libraries that do things like 
that, but it's definitely a Hibernate bug.

Someone else will have to talk the locking behavior you're seeing. Are you 
starting Ignite more than once in parallel in that case?

On Wed, Jan 13, 2016 at 8:23 AM, Yann BLAZART 
<yann.blaz...@externe.bnpparibas.com<mailto:yann.blaz...@externe.bnpparibas.com>>
 wrote:
Hello everybody.

I’m currently evaluation Ignite vs Hazelcast on a poc.

I’m facing some issues.
I’m coding some integration/unit test using the ApplicationComposer of TomEE 
7.0.0. I have no problem with Hazelcast on it.


•         The first one is when I’m start Ignite in the applicationComposer 
(with a CDI @Produces), Ignite complain about some System.properties that are 
not String :


it try to "serialize" System.properties by using 
System.getProperties().store(new PrintWriter(sw));



In fact, TomEE (as other framework like hibernate) use System.properties to 
store prop objects.



So I made something to remove this properties before Ignite start and recover 
its after. Well. Pehraps it will be nice to change the way to “serialize” 
System.properties.



•         The second problem is strange, very strange. If I’m making a call to 
Ignite.start in @Before or using a @Inject in the test class (that use the 
@Produce that make the call to start(), everything is ok. But if the start is 
called in the @Test method (so after ApplicationComposer has made some things), 
Ignite is “locked”.

o   Precisely in IgniteKernel.java:917  :



// Start discovery manager last to make sure that grid is fully initialized.
startManager(discoMgr);



                The call to  this method never exit.



Any idea to help me to understand ? Anybody has tried to use Ignite with EE or 
CDI ?



Regards






This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply via email to