Jon Stevens wrote:
>
> Ok,
>
> Here is a reason to *not* allow Geir's recent case "feature" into the
> introspection...
I am not sure that there is a 'reason' in there. I can't figure out
what it's saying :)
This actually may support ('may', because it isn't clear what exactly
your JMX snippet is trying to say...) what I was saying about our
inverted interpretation of the bean spec, namely that the bean spec
directly addresses the notion of finding a pair of methods, getFoo and
setFoo, and therefore concluding that there is a property 'foo', by
making the statement that when you have a property 'Foo', it should be
cased according to rules in sec 8.9 (or near there), namely Foo -> foo
In Velocity, we do the inverse, finding a property-like reference in a
template like $foo.bar and then go flailing about to find something that
matches, namely getbar() or getBar()
One gets the sense, when confronted with the bean spec (which leaves
things wide open, IMO) and the JMX spec, that someone isn't minding the
store :)
As for comments on the snippet you included, I am confused :
If the snippet said something like "this means that the methods getstate
and getState define two attributes, state and State...." but I already
can infer that getstate() gives me something readable, and setState() is
something writeable.
I guess I find that snipped below somewhat difficult to understand,
actually, and if not in actual conflict with the bean spec, certainly
adding confusion.
As to the applicability to Velocity, I think we have to find out more.
If common practice is going towards something horrible like encouraging
people writing classes/interfaces that have methods getstate() and
getState(), then we have a problem. [And I think the problem isn't in
velocity, but Java coding standards overall :) ]
We can also just have a switch to turn off anything but 'explicit
introspection'.
geir
>
> Page 40 of Sun's JMX Spec PDF ("jmx_instr_agent.pdf"):
>
> "Case Sensitivity
>
> All attribute and operation names derived from these design patterns are
> case-sensitive. For example, this means that the methods getstate and
> setState define two attributes, one called state that is read-only, and one
> called State that is write-only. While case sensitivity applies directly to
> component names of standard MBeans, it is also applicable to all component
> names of all types of MBeans, standard or dynamic. In general, all names of
> classes, attributes, operations, methods, and internal elements defined in
> the JMX specification are case sensitive, whether they appear as data or as
> functional code when they are manipulated by management operations."
>
> Comments?
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/> | <http://java.apache.org/turbine/>
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
