Jerome/Kohsuke,
PRELUDE
I know how complex it is to start a major new project, but I want to
be completely clear on this: I'm finding the HK2 and related
documentation very difficult to follow.
A project cannot succeed with sparse documentation that requires
"insider insights" to understand—that's the way it feels to me when I
read it. The clarity and detail of the documentation cause me to
have to read and re-read, trying to glean more insight.
I strongly suggest that time be set aside to expand upon the
documentation. I will contribute to that effort by first raising
questions, whose answers should be incorporated somewhere in the
documentation, following any email discussion. Later, when I
understand it better, I will contribute to the documentation as well.
It's confusing to have HK2 separated from GlassFish V3. Back and
forth, and way too few cross-links. They seem so intimately
connected that IMO they should be more closely connected on the web
page.
QUESTIONS/COMMENTS
I refer to "GlassFish v3 Config.pdf" (where is that document on the
web site?). Most of these issues I previously raised in our meeting,
but I have seen no revision to any materials to suggest that any
design alternatives have been considered.
1. The comment (on the "AMX" page) that "we can’t be manually
writing com.sun.appserv.management.config interfaces" is nonsensical
to me--from I can see, we are regressing from an interface-based
approach to a concrete-class-based approach, where the module author
is now writing concrete classe(s) instead of interfaces. It's far
from clear that this is an improvement.
=> Interfaces are going to be needed(regardless of who writes them),
so why are we encouraging concrete classes (with possible thread-
safety issues due to injection)? It seems to me that we are
introducing a more complex (and poorly-documented/explained IMO)
series of annotations for what could be done more simply with an
interface (for 90% of the common cases). AMX has no a-priori
limitations to being generalized to allow pluggable MBeans whose
interfaces are written post-ship, so the "manually" comment should be
stricken as inaccurate and misleading.
2. Why should injection set (mutate) N fields when it could instead
inject a single (thread-safe) object containing those values, one
that implements a configuration interface, and one that might just
happen to also be a JMX MBean? Kill 3 birds with one stone.
3. I don't understand the containment hierarchy for configuration
objects. Is there a strict containment hierarchy, or can
configuration be M to N? With AMX, any configuration element
(implements Config, Containee) is contained by exactly one
Container. Code that uses that configuration is not limited in any
way, but the concept of a containment hierarchy for hierarchical
configuration should be a separate concept from the *references* to
all or some of that hierarchy. A good example is the HTTPService and
its HTTPListeners, VirtualServers, SSLConfig, etc.
4. The injection model seems to be "by reference". Is that true?
How is thread safety handled when fields are (apparently) directly
accessible, especially if an array were read and written by different
threads at the same time?
Thanks,
Lloyd Chambers