[infinispan-dev] Issue with JGroups config files in ispn-core
sanne at infinispan.org
Thu Jun 12 19:44:08 EDT 2014
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
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.
> On 06/12/2014 07:44 AM, Alan Field wrote:
>> So the server and library configuration parsers will handle something like this?
>> <stack-file name="jgroupsStack" path="config/jgroups-udp.xml"/>
>> If this is true, then I agree that this is a good solution as well.
>> ----- 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.
>>> On 12/06/14 14:30, Martin Gencur wrote:
>>>> 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
>>>> 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 ?
>>>> ? (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
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
More information about the infinispan-dev