IntelliJ IDEA license renewal for ISPN OS project
by Tomas Sykora
Hello all,
current open source Infinispan license for IntelliJ IDEA expires in 3 days. Is there any way how we can obtain a new one for next year?
IIRC, Manik took care about this issue.
Thanks!
Tomas
10 years
Re: [infinispan-dev] Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net
by Galder Zamarreño
Thanks Dalibor!
On 23 May 2014, at 12:24, dalibor topic <dalibor.topic(a)oracle.com> wrote:
> It was. See https://bugs.openjdk.java.net/browse/JDK-8037801 for details.
>
> On 23.05.2014 11:12, Galder Zamarreño wrote:
>> Hi Rory,
>>
>> Is https://bugs.openjdk.java.net/browse/JDK-8036554 being backported to 7u60?
>>
>> Cheers,
>>
>> On 23 May 2014, at 10:11, Rory O'Donnell Oracle, Dublin Ireland <rory.odonnell(a)oracle.com> wrote:
>>
>>> Hi Galder,
>>>
>>> Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net.
>>>
>>> As we enter the later phases of development for JDK 7u60 & JDK 8u20 , please log any show
>>> stoppers as soon as possible.
>>>
>>> Rgds, Rory
>>>
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>>
>>
>> --
>> Galder Zamarreño
>> galder(a)redhat.com
>> twitter.com/galderz
>>
>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
10 years
Re: [infinispan-dev] Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15 are available on java.net
by Rory O'Donnell
Thanks Dalibor.
On 23/05/2014 11:24, dalibor topic wrote:
> It was. See https://bugs.openjdk.java.net/browse/JDK-8037801 for details.
>
> On 23.05.2014 11:12, Galder Zamarreño wrote:
>> Hi Rory,
>>
>> Is https://bugs.openjdk.java.net/browse/JDK-8036554 being backported
>> to 7u60?
>>
>> Cheers,
>>
>> On 23 May 2014, at 10:11, Rory O'Donnell Oracle, Dublin Ireland
>> <rory.odonnell(a)oracle.com> wrote:
>>
>>> Hi Galder,
>>>
>>> Early Access builds for JDK 9 b13, JDK 8u20 b15 and JDK 7u60 b15
>>> are available on java.net.
>>>
>>> As we enter the later phases of development for JDK 7u60 & JDK 8u20
>>> , please log any show
>>> stoppers as soon as possible.
>>>
>>> Rgds, Rory
>>>
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>>
>>
>> --
>> Galder Zamarreño
>> galder(a)redhat.com
>> twitter.com/galderz
>>
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years
JPA CacheStore doc
by Emmanuel Bernard
Hi guys,
I was reading http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_jpa_cache_store
I have a few remarks and questions.
The links on 7.3. Additional References to github lead to 404.
Right under the 7. Section title, there is
The Infinispan Community :icons: font
Not sure what that it.
The documentation does not mention support or lack of for associations. I suppose this should be covered.
Anyone can lead this? Should I open JIRAs?
Emmanuel
10 years
Re: [infinispan-dev] infinispan 5.3.0 build issues
by Sanne Grinovero
Hi,
On 21 May 2014 11:12, Mohan Dhawan <mohan.dhawan(a)gmail.com> wrote:
> Hi Sanne,
>
> Thanks for the prompt response. I'm getting the same error.
>
> How can I 'activate' the JBoss.org Maven repository ? There is a
> maven-settings.xml file.
The standard way in Maven is tu use the -s parameter, so:
# mvn clean install -s maven-settings.xml
More recent versions include a build script; I'd advise to use the latest.
Instructions to make it permantently available by default are here:
https://community.jboss.org/wiki/MavenGettingStarted-Users
But if you're new to these build systems I'd suggest to read the
chapter about building first:
https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan
Regards,
Sanne
>
> Regards,
> mohan
>
>
> On Wednesday 21 May 2014 03:38 PM, Sanne Grinovero wrote:
>>
>> Hi,
>> do you mean you have literally the same error? If not it would help to
>> see the exact error message.
>>
>> Generally speaking if your error refers to missing dependencies, is it
>> possible that you have not activated the JBoss.org Maven repository?
>> There should be an example maven-settings.xml file included in the
>> root of the sources.
>>
>> I've included the developers mailing list in CC, please use that for
>> development related questions.
>> Alternatively, it's probably easier for this kind of problems to ask on
>> IRC.
>> Details for both IRC and the mailing lists can be found here:
>> http://infinispan.org/community/
>>
>> Regards,
>> Sanne
>>
>>
>> On 21 May 2014 09:05, Mohan Dhawan <mohan.dhawan(a)gmail.com> wrote:
>>>
>>> Hi Adrian, Sanne,
>>>
>>> I'm trying to build infinispan-5.3.0 from source --- I checked out a .zip
>>> of
>>> the source from GitHub and branch 5.3.x. However, I'm still getting build
>>> errors similar to those listed here
>>> (http://lists.jboss.org/pipermail/infinispan-dev/2013-July/013448.html).
>>>
>>> Kindly advise.
>>>
>>> Regards,
>>> mohan
>
>
10 years
Re: [infinispan-dev] infinispan 5.3.0 build issues
by Sanne Grinovero
Hi,
do you mean you have literally the same error? If not it would help to
see the exact error message.
Generally speaking if your error refers to missing dependencies, is it
possible that you have not activated the JBoss.org Maven repository?
There should be an example maven-settings.xml file included in the
root of the sources.
I've included the developers mailing list in CC, please use that for
development related questions.
Alternatively, it's probably easier for this kind of problems to ask on IRC.
Details for both IRC and the mailing lists can be found here:
http://infinispan.org/community/
Regards,
Sanne
On 21 May 2014 09:05, Mohan Dhawan <mohan.dhawan(a)gmail.com> wrote:
> Hi Adrian, Sanne,
>
> I'm trying to build infinispan-5.3.0 from source --- I checked out a .zip of
> the source from GitHub and branch 5.3.x. However, I'm still getting build
> errors similar to those listed here
> (http://lists.jboss.org/pipermail/infinispan-dev/2013-July/013448.html).
>
> Kindly advise.
>
> Regards,
> mohan
10 years
Welcome to Gustavo
by Bilgin Ibryam
Welcome Gustavo.
It is great to be colleagues again.
On 15 May 2014 14:29, <infinispan-dev-request(a)lists.jboss.org> wrote:
> Send infinispan-dev mailing list submissions to
> infinispan-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> or, via email, send a message with subject or body 'help' to
> infinispan-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> infinispan-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of infinispan-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [!] Reorganization of dependencies & release process
> (Sanne Grinovero)
> 2. Re: Configuration XSD missing, Infinispan not parsing v.6
> configuration files ? (Pedro Ruivo)
> 3. Re: Configuration XSD missing, Infinispan not parsing v.6
> configuration files ? (Sanne Grinovero)
> 4. Re: Clustered Listener (William Burns)
> 5. Welcome to Gustavo (Sanne Grinovero)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 May 2014 13:45:04 +0100
> From: Sanne Grinovero <sanne(a)infinispan.org>
> Subject: Re: [infinispan-dev] [!] Reorganization of dependencies &
> release process
> To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> Cc: Hardy Ferentschik <hardy(a)hibernate.org>
> Message-ID:
> <
> CAFm4XO1Dev09T+fyVw6OrxV40hGE9-MR3BUVw1gJsXuTnJsppw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 14 May 2014 13:19, Adrian Nistor <anistor(a)redhat.com> wrote:
> > +1 for moving Infinispan lucene directory out
> >
> > But why move Query components out? And which ones did you have in mind?
>
> Because it depends on the Directory, but also on Hibernate Search, so
> it "mandates" a specific version of Apache Lucene.
> By moving these out of the core release, we can make Infinispan (core)
> releases independently from specific Lucene versions.
>
> Lucene lately is being quite aggressive in changes, and so doing we
> can have a single point of surgery at a time: the Directory first, tag
> it. Search, tag it.
> Then Infinispan Query and Infinispan full releases. Note how each
> component has the freedom to choose to *not* update Lucene or *not*
> update Infinispan core, if it needs to make unrelated fixes available
> early on.
>
> So I think it's necessary to move all Query components out too, seems
> like the only way out. A more open question is if other components
> would benefit from a similar model? I think so, although the reasons
> are less urgent.
>
> Sanne
>
> >
> > On 05/14/2014 12:50 AM, Sanne Grinovero wrote:
> >> This is a reboot of the thread previously started on both the
> >> infinispan-dev and the hibernate-dev mailing list as "Handling of
> >> mutual dependency with Infinispan" [1].
> >> We discussed further during the Hibernate fortnightly meeting [2], and
> >> came to the conclusion that we need Infinispan to change how some
> >> repositories are organised and how the release is assembled.
> >>
> >> # The problem
> >>
> >> To restate the issue, as you might painfully remember, every time
> >> there is a need for a Lucene update or a Search update we need to sync
> >> up for a complex dance of releases in both projects to accommodate for
> >> a small-step iterative process to handle the circular dependency.
> >> This problem is not too bad today as since a year we're releasing the
> >> Lucene Directory in an unusual - and very unmaintainable - temporary
> >> solution to be compatible with two different major versions of Apache
> >> Lucene; namely what Infinispan Query needs and what Hibernate Search
> >> needs are different modules.
> >> But the party is over, and I want to finally drop support for Lucene 3
> >> and cleanup the unusual and unmaintainable build mess targeting a
> >> single Lucene version only.
> >> As soon as we converge to building a single version however - we're
> >> back to the complex problem we had when we supported a single version
> >> which is handling of a circular dependency - just that the problem has
> >> worsened lately the Lucene project has been more active and more
> >> inclined than what it used to be to break both internal and public
> >> APIs.
> >>
> >> In short, we have a circular dependency between Hibernate Search and
> >> Infinispan which we've been able to handle via hacks and some luck,
> >> but it imposes a serious threat to development flexibility, and the
> >> locked-in release process is not desirable either.
> >>
> >> # The solution
> >>
> >> we think in conclusion there's a single "proper" way out, and it also
> >> happens to provide some very interesting side effects in terms of
> >> maintenance overhead for everyone: Infinispan Core needs to release
> >> independently from the non-core modules.
> >> This would have the Lucene Directory depend on a released tag of
> >> infinispan-core, and be able to be released independently.
> >> Minor situations with benefit:
> >> - we often don't make any change in the Lucene Directory, still we
> >> need to release it.
> >> - when I actually need a release of it, I'm currently begging for a
> >> quick release of Infinispan: very costly
> >> The Big Ones:
> >> - we can manage the Lucene Directory to provide support for different
> >> versions of Lucene without necessarily breaking other modules
> >> - we can release quickly what's needed to move Search ahead in terms
> >> of Lucene versions without needing to make the Infinispan Query module
> >> compatible at the same time (in case you haven't followed this area:
> >> this seems to be my main activity rather than making valuable stuff).
> >>
> >> The goal is of course to linearise the dependencies; it seems to also
> >> simplify some of our tasks which is a welcome side-effect. I expect it
> >> also to make the project less scary for new contributors.
> >>
> >> # How does it impact users
> >>
> >> ## Maven users
> >> modules will continue to be modules.. I guess nobody will notice,
> >> other than we might have a different versioning scheme, but we help
> >> people out via the Infinispan BOM.
> >>
> >> ## Distribution users
> >> There should be no difference, other than (as well) some jars might
> >> not be aligned in terms of version. But that's probably even less of a
> >> problem, as I expect distribution users to just put what they get on
> >> their classpath.
> >>
> >> # How it impacts us
> >>
> >> 1) I'll move the Lucene Directory project to an different repository;
> >> same for the Query related components.
> >> I think you should/could consider the same for other components, based
> >> on ad-hoc considerations of the trade offs, but I'd expect ultimately
> >> to see a more frequent and "core only" release.
> >>
> >> 2) We'll have different kinds of releases: the "core only" and the
> >> "full releases".
> >> I think we'll also see components being released independently, but
> >> these are either Maven-only or meant for preparation of other
> >> components, or preparation for a "full release".
> >>
> >> 3) Tests (!)
> >> Such a move should in no way relax the regression-safety of
> >> infinispan-core: we need to still consider it unacceptable for a core
> >> change to break one of the modules moving out of the main tree.
> >> Personally I think I've pushed many tests about problems found in the
> >> "query modules" as unit tests in core, so that should be relatively
> >> safe, but it also happened that someone would "tune" these.
> >> I realise it's not practical to expect people to run tests of
> >> downstream modules, so we'll have to automate most of these tasks in
> >> CI.
> >> Careful on perception: if today there are three levels of defence
> >> against a regression (the author, the reviewer and CI all running the
> >> suite for each change), in such an organisation you have only one. So
> >> ignoring a CI failure as a "probable hiccup" could be much more
> >> dangerous than usual.
> >>
> >> # When
> >>
> >> Doing this _might_ be a blocker for any Lucene update; so since one
> >> just happened I'll probably have no urgent need for a couple of weeks
> >> at least.
> >> But we shouldn't be in a position in which an update could not be
> >> possible, so I hope we'll agree to implement this sooner rather than
> >> later, so we won't have to do it during an emergency.
> >>
> >> Also while this might sound a bit crazy at first, I see many
> >> flexibility benefits which can't hurt now that the project is getting
> >> larger and more complex to release.
> >> Not least, having a micro release of "Infinispan essentials" would be
> >> very welcome in terms of lowing the initial barrier; this was proposed
> >> at various meetings and highly endorsed by many but just never
> >> happened.
> >>
> >> Any comment please? I hope I covered it all, and sorry for that :D
> >>
> >> Cheers,
> >> Sanne
> >>
> >>
> >> 1 - http://lists.jboss.org/pipermail/hibernate-dev/2014-May/011419.html
> >> 2 -
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/...
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 May 2014 14:00:17 +0100
> From: Pedro Ruivo <pedro(a)infinispan.org>
> Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan
> not parsing v.6 configuration files ?
> To: infinispan-dev(a)lists.jboss.org
> Message-ID: <537368E1.6020206(a)infinispan.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Sanne,
>
> I have added the 7.0 schemas to infinispan.org/schemas.
>
> About the 6.0 parsing, yes I think it was supposed to be not parsed :P I
> think I saw some warning about this change but I can't find it (so maybe
> I was dreaming). So, agree with you. we need an upgrade guide (however,
> the documentation already uses the new style)
>
> Cheers,
> Pedro
>
> On 05/14/2014 01:32 PM, Sanne Grinovero wrote:
> > On 14 May 2014 09:58, Pedro Ruivo <pedro(a)infinispan.org> wrote:
> >> yes, the release process put the schema here:
> >> http://docs.jboss.org/infinispan/schemas/
> >
> > Thanks, I'll use that. But shouldn't we have it at the URL I posted too??
> >
> > And is it really expected that we don't parse old-style configuration
> files?
> > That's quite annoying for users. If it's the intended plan, I'm not
> > against it but we'd need some clear warning and also some guidance for
> > an upgrade.
> > (BTW great job on the documentation updates)
> >
> > Cheers,
> > Sanne
> >
> >>
> >> Pedro
> >>
> >> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:
> >>> Isn't the deployment of XSDs part of the release process ?
> >>>
> >>> Tristan
> >>>
> >>> On 14/05/2014 01:36, Sanne Grinovero wrote:
> >>>> The testing configuration files seem to point to this URL:
> >>>> http://www.infinispan.org/schemas/infinispan-config-7.0.xsd
> >>>>
> >>>> But I'm getting a 404 when attempting to find it.
> >>>>
> >>>> It would be very helpfull to make this available, as it seems
> >>>> Infinispan 7.0.0.Alpha4 is unable to read the old configuration format
> >>>> :-(
> >>>>
> >>>> Is that expected?
> >>>>
> >>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'
> >>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:100)
> >>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromStream(TestCacheManagerFactory.java:106)
> >>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:97)
> >>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:91)
> >>>> at
> org.infinispan.manager.CacheManagerXmlConfigurationTest.testBatchingIsEnabled(CacheManagerXmlConfigurationTest.java:126)
> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>>> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>> at java.lang.reflect.Method.invoke(Method.java:606)
> >>>> at
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> >>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> >>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> >>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> >>>> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> >>>> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> >>>> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> >>>> at org.testng.TestRunner.run(TestRunner.java:617)
> >>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> >>>> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> >>>> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> >>>> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> >>>> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>> at java.lang.Thread.run(Thread.java:744)
> >>>> Caused by: javax.xml.stream.XMLStreamException: ParseError at
> [row,col]:[5,41]
> >>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'
> >>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:137)
> >>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:121)
> >>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:108)
> >>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:95)
> >>>> ... 24 more
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 May 2014 16:16:12 +0100
> From: Sanne Grinovero <sanne(a)infinispan.org>
> Subject: Re: [infinispan-dev] Configuration XSD missing, Infinispan
> not parsing v.6 configuration files ?
> To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAFm4XO2NncDr6z9KSiRH70bNK_gmMMDw2HSD9CM+1NJ3Z6p2Hw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 14 May 2014 14:00, Pedro Ruivo <pedro(a)infinispan.org> wrote:
> > Hi Sanne,
> >
> > I have added the 7.0 schemas to infinispan.org/schemas.
>
> Thanks!
>
> >
> > About the 6.0 parsing, yes I think it was supposed to be not parsed :P I
> > think I saw some warning about this change but I can't find it (so maybe
> > I was dreaming). So, agree with you. we need an upgrade guide (however,
> > the documentation already uses the new style)
>
> Yes the docs are very nice. I guess my problem is just that it's an
> unexpected issue; I somehow guess it from the stacktrace but I don't
> think everyone will be as familiar with the kind of error message.
> I'll open an issue to improve the error; if ever someone will
> volunteer to also write a couple of lines on how to migrate, we could
> link the page from the error message.
>
> >
> > Cheers,
> > Pedro
> >
> > On 05/14/2014 01:32 PM, Sanne Grinovero wrote:
> >> On 14 May 2014 09:58, Pedro Ruivo <pedro(a)infinispan.org> wrote:
> >>> yes, the release process put the schema here:
> >>> http://docs.jboss.org/infinispan/schemas/
> >>
> >> Thanks, I'll use that. But shouldn't we have it at the URL I posted
> too??
> >>
> >> And is it really expected that we don't parse old-style configuration
> files?
> >> That's quite annoying for users. If it's the intended plan, I'm not
> >> against it but we'd need some clear warning and also some guidance for
> >> an upgrade.
> >> (BTW great job on the documentation updates)
> >>
> >> Cheers,
> >> Sanne
> >>
> >>>
> >>> Pedro
> >>>
> >>> On 05/14/2014 07:50 AM, Tristan Tarrant wrote:
> >>>> Isn't the deployment of XSDs part of the release process ?
> >>>>
> >>>> Tristan
> >>>>
> >>>> On 14/05/2014 01:36, Sanne Grinovero wrote:
> >>>>> The testing configuration files seem to point to this URL:
> >>>>> http://www.infinispan.org/schemas/infinispan-config-7.0.xsd
> >>>>>
> >>>>> But I'm getting a 404 when attempting to find it.
> >>>>>
> >>>>> It would be very helpfull to make this available, as it seems
> >>>>> Infinispan 7.0.0.Alpha4 is unable to read the old configuration
> format
> >>>>> :-(
> >>>>>
> >>>>> Is that expected?
> >>>>>
> >>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'
> >>>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:100)
> >>>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromStream(TestCacheManagerFactory.java:106)
> >>>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:97)
> >>>>> at
> org.infinispan.test.fwk.TestCacheManagerFactory.fromXml(TestCacheManagerFactory.java:91)
> >>>>> at
> org.infinispan.manager.CacheManagerXmlConfigurationTest.testBatchingIsEnabled(CacheManagerXmlConfigurationTest.java:126)
> >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>>> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>>>> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>>> at java.lang.reflect.Method.invoke(Method.java:606)
> >>>>> at
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> >>>>> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> >>>>> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> >>>>> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> >>>>> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> >>>>> at
> org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> >>>>> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> >>>>> at org.testng.TestRunner.run(TestRunner.java:617)
> >>>>> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> >>>>> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> >>>>> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> >>>>> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> >>>>> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>> at java.lang.Thread.run(Thread.java:744)
> >>>>> Caused by: javax.xml.stream.XMLStreamException: ParseError at
> [row,col]:[5,41]
> >>>>> Message: Unexpected element '{urn:infinispan:config:6.0}infinispan'
> >>>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:137)
> >>>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:121)
> >>>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:108)
> >>>>> at
> org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:95)
> >>>>> ... 24 more
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> infinispan-dev(a)lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 15 May 2014 09:08:38 -0400
> From: William Burns <mudokonman(a)gmail.com>
> Subject: Re: [infinispan-dev] Clustered Listener
> To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> Message-ID:
> <CA+YCuUOsJ4ugVtg=8n=
> eZO0P5+sYxWgKC_paeh9vZLH_TY7-rg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, May 13, 2014 at 9:10 AM, Pierre Sutra <pierre.sutra(a)unine.ch>
> wrote:
> > Hello,
> >
> > As part of the LEADS project, we have been using recently the clustered
> > listeners API. In our use case, the application is employing a few
> > thousands listeners, constantly installing and un-installing them.
>
> Are you talking about non clustered listeners? It seems unlikely you
> would need so many cluster listeners. Cluster listeners should allow
> you to only install a small amount of them, usually you would have
> only additional ones if you have a Filter applied limiting what
> key/values are returned.
>
> > The
> > overall picture is that things work smoothly up to a few hundreds
> > listeners, but above the cost is high due to the full replication
> > schema. To sidestep this issue, we have added a mechanism that allows
> > listening only to a single key.
>
> Is the KeyFilter or KeyValueFilter not sufficient for this?
>
> void addListener(Object listener, KeyFilter<? super K> filter);
>
> <C> void addListener(Object listener, KeyValueFilter<? super K, ?
> super V> filter, Converter<? super K, ? super V, C> converter);
>
> Also to note if you are doing any kind of translation of the value to
> another value it is recommended to do that via the supplied Converter.
> This can give good performance as the conversion is done on the
> target node and not all in 1 node and also you can reduce the payload
> if the resultant value has a serialized form that is smaller than the
> original value.
>
> > In such a case, the listener is solely
> > installed at the key owners. This greatly helps the scalability of the
> > mechanism at the cost of fault-tolerance since, in the current state of
> > the implementation, listeners are not forwarded to new data owners.
> > Since as a next step [1] it is planned to handle topology change, do you
> > plan also to support key (or key range) specific listener ?
>
> These should be covered with the 2 overloads as I mentioned above.
> This should be the most performant way as the filter is replicated to
> the node upon installation so a 1 time cost. But if a key/value pair
> doesn't pass the filter the event is not sent to the node where the
> listener is installed.
>
> > Besides,
> > regarding this last point and the current state of the implementation, I
> > would have like to know what is the purpose of the re-installation of
> > the cluster listener in case of a view change in the addedListener()
> > method of the CacheNotifierImpl class.
>
> This isn't a re-installation. This is used to propgate the
> RemoteClusterListener to the other nodes, so that when a new event is
> generated it can see that and subsequently send it back to the node
> where the listener is installed. There is also a second check in
> there in case if a new node joins in the middle.
>
> > Many thanks in advance.
>
> No problem, glad you guys are testing out this feature already :)
>
> >
> > Best,
> > Pierre Sutra
> >
> > [1]
> >
> https://github.com/infinispan/infinispan/wiki/Clustered-listeners#handlin...
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 15 May 2014 14:29:17 +0100
> From: Sanne Grinovero <sanne(a)infinispan.org>
> Subject: [infinispan-dev] Welcome to Gustavo
> To: infinispan -Dev List <infinispan-dev(a)lists.jboss.org>
> Message-ID:
> <CAFm4XO19aw3Uadiq0L0mimqgqZiOaTyWFr-G_=
> 5KSKEd3DEQxw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi all,
> today we finally have Gustavo joining us as a full time engineer on
> Infinispan.
>
> He worked with Tristan and myself in Italy before we came to Red Hat,
> and was already a Lucene expert back then. He then joined Red Hat as a
> consultant but that didn't last too long: he was too good and
> customers wanted him to travel an unreasonable amount.
>
> So he has been lost for a couple of years, but wisely spent them to
> deepen his skills in devops, more of Lucene but now in larger scale
> and distributed environments: a bit of JGroups, Infinispan and
> Hibernate Search and even some Scala, but also experience with
> MongoDB, Hadoop, Elastic Search and Solr so I'm thrilled to have this
> great blend of competences now available full time to improve the
> Search experience of Infinispan users.
>
> Welcome!
>
> He's gustavonalle on both IRC and GitHub.
>
> Sanne
>
>
> ------------------------------
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> End of infinispan-dev Digest, Vol 62, Issue 12
> **********************************************
>
--
Bilgin Ibryam
Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>
Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475
10 years
