Hey Lincoln,
Thanks a lot for reporting this. It's definitely an interesting idea that reduces the
number of invalid fluent configuration calls, but I doubt we'll be making changes in
the short term, since we've already changed configuration twice and we're still
trying to get rid of the two previous ways to configure Infinispan. I think evolving this
further at this stage it's probably gonna cause a bit of chaos, and judging from the
code, seems like it'd require a rewrite.
I don't know if there's already any JIRAs to further enhance configuration for
future Infinispan versions, but regardless, you should probably put all of this into a
JIRA and let us know the link so that we can schedule it, and maybe group it with other
potential configuration changes we might wanna do.
Cheers,
On Sep 9, 2013, at 11:39 PM, "Lincoln Baxter, III"
<lincolnbaxter(a)gmail.com> wrote:
Thought.
It seems very easy to do things with the fluent builder API that either have no effect or
have little effect - such as:
new ConfigurationBuilder().clustered().clustered().clustered()
While this is probably not a problem. The call to `.clustered()` could return a
sub-configuration interface that would ultimately return an intermediate interface, only
declaring methods that may be used to configure a cluster - thus making such a declaration
syntactically illegal. Once a valid configuration state on this object (and its
sub-objects) is reached, the returned interface type would present the user with a
`ClusteredConfigurationBuilder`, e.g. a ConfigurationBuilder that is already clustered,
and cannot be used to configure a cluster.
I'm fully aware of how many interfaces this would require, but I also have a proof of
concept that has shown to be very practically successful in eliminating user error for
complex configurations, and has been well worth the effort:
https://github.com/ocpsoft/rewrite/blob/master/api-tests/src/test/java/or...
The above test does not verify invalid configuration ordering because it is actually a
compilation error and cannot be tested with JUnit! But hopefully you get the idea.
You can see the hierarchy of this (probably simpler than infinispan) configuration
builder API here:
https://github.com/ocpsoft/rewrite/tree/master/api/src/main/java/org/ocps...
Any class that starts with "Configuration..." is part of the relevant API.
Also, you could avoid an API-breaking change if provided a TypesafeConfigurationBuilder
that simply delegates to the current ConfigurationBuilder API.
Thoughts?
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org