No, I understand that you can't control what other projects do, and it's not always possible to fix bugs at their source.
I imagine the best thing for Ignite to do in this case is to iterate through the properties and just ignore anything that isn't a String. It wouldn't be meaningful when deserialized anyway. On Wed, Jan 13, 2016 at 10:26 AM, Yann BLAZART < [email protected]> wrote: > 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:[email protected]] > *Sent:* mercredi 13 janvier 2016 15:31 > *To:* [email protected] > *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 < > [email protected]> 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. > > >
