[infinispan-dev] Issue with JGroups config files in ispn-core

Martin Gencur mgencur at redhat.com
Fri Jul 11 02:58:12 EDT 2014


OK, I filed this one: https://issues.jboss.org/browse/ISPN-4499

Martin

On 13.6.2014 10:08, Tristan Tarrant wrote:
> Let me add:
>
> specifying a configuration file just by name is NOT enough. We also need
> to allow users to specify an InputStream which IMHO is the "only correct
> way" :)
>
> Tristan
>
> On 13/06/14 01:44, Sanne Grinovero wrote:
>> On 12 June 2014 17:46, Dennis Reed <dereed at redhat.com> wrote:
>>> +1 to changing the name/directory.
>>> -100 to changing the order of where it's looked for instead.
>>>
>>> All resource lookups should use the normal rules for finding resources.
>>> Don't change standard behavior without a *very* good reason.
>> There isn't a "standard behaviour", the problem is exactly that it's
>> not defined.
>> By actually specifying an order we can decide that a user
>> configuration file will take priority over our own file, at least
>> assuming a modular classloader is being used.
>> So indeed it's not a solution for flat classloaders, but it's at least
>> correct in that case.
>>
>> This is what we do in other frameworks: the order in which you look
>> for resources needs to be well defined, but it's not in Infinispan.
>>
>>> Doing anything special (like META-INF/_internal/jgroups-udp.xml) is
>>> completely non-intuitive
>>> and will cause support issues down the road.
>>> Using config/jgroups-udp.xml is standard, and would be immediately
>>> understood by anyone.
>> I would agree with you about this being a common expectation, but it's
>> not rock-solid; we still can't state for sure that the user won't use
>> "config" directory too..
>>
>> The only foolproof solution is to store some signature of the
>> jgroups-udp.xml hardcoded in a class, or simply hardcode the whole
>> file as a constant.
>> We could use the maven inject plugin to maintain the xml file as
>> normal source code, and "seal" some constant at build time.. but I
>> don't think it's worth it as by defining the lookup order the problem
>> is solved in JBoss or WildFly as we would know that the
>> infinispan-core.jar classloader is different than the user one, unless
>> people bundle the Infinispan jars in their app.
>>
>> Considering JGroups already logs the full configuration file that it's
>> applying, maybe it could log some hash signature as well? This way you
>> could just compare the signature to make sure it's using some "well
>> known" configuration file.
>>
>> Sanne
>>
>>
>>> -Dennis
>>>
>>> On 06/12/2014 07:44 AM, Alan Field wrote:
>>>> Tristan,
>>>>
>>>> So the server and library configuration parsers will handle something like this?
>>>>
>>>>        <jgroups>
>>>>            <stack-file name="jgroupsStack" path="config/jgroups-udp.xml"/>
>>>>        </jgroups>
>>>>
>>>> If this is true, then I agree that this is a good solution as well.
>>>>
>>>> Thanks,
>>>> Alan
>>>>
>>>> ----- Original Message -----
>>>>> From: "Tristan Tarrant" <ttarrant at redhat.com>
>>>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>>>> Sent: Thursday, June 12, 2014 2:37:22 PM
>>>>> Subject: Re: [infinispan-dev] Issue with JGroups config files in ispn-core
>>>>>
>>>>> I think the "internal" jgroups files should be "moved" to a separate
>>>>> directory within the core jar, to be searched after the "root". So the
>>>>> user can still provide a jgroups-udp.xml and it won't conflict.
>>>>>
>>>>> Tristan
>>>>>
>>>>> On 12/06/14 14:30, Martin Gencur wrote:
>>>>>> Hi,
>>>>>> let me mention an issue that several people faced in the past,
>>>>>> independently of each other:
>>>>>>
>>>>>> A user app uses a custom JGroups configuration file. However, they
>>>>>> choose the same name as the files which we bundle inside
>>>>>> infinispan-core.jar.
>>>>>> Result? People are wondering why their custom configuration does not
>>>>>> take effect.
>>>>>> Reason? Infinispan uses the default jgroups file bundled in infinispan-core
>>>>>> Who faced the issue? (I suppose it's just a small subset:)) Me, Radim,
>>>>>> Alan, Wolf Fink
>>>>>>
>>>>>> I believe a lot of users run into this issue.
>>>>>>
>>>>>> We were considering a possible solution and this one seems like it could
>>>>>> work (use both 1) and 2)):
>>>>>> 1) rename the config files in the distribution e.g. this way:
>>>>>> jgroups-ec2.xml -> default-jgroups-ec2.xml
>>>>>> jgroups-udp.xml -> default-jgroups-udp.xml
>>>>>> jgroups-tcp.xml -> default-jgroups-tcp.xml
>>>>>>
>>>>>> Any other suggestions? internal-jgroups-udp.xml ?
>>>>>> dontEverUseThisFileInYourAppAsTheCustomConfigurationFile-jgroups-udp.xml
>>>>>> ? (joke)
>>>>>> (simply something that users would automatically like to change once
>>>>>> they use it in their app)
>>>>>>
>>>>>> 2) Throw a warning whenever a user wants to use a custom jgroups
>>>>>> configuration file that has the same name as one of the above
>>>>>>
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks!
>>>>>> Martin
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list