Jason,
Thanks...response inline.
Lloyd
On Jan 28, 2009, at 7:41 AM, Justin Lee wrote:
> Comments in line
>
> Lloyd Chambers wrote:
>> llc01 -- The spec is a little odd in that we have no DTD in V3,
>> only generated XML based on java interfaces, and those java
>> interfaces are nowhere to be found. Especially in a spec, this is
>> a confusing way to put it without first stating that what is shown
>> is to make the structure clear for discussion purposes, and not an
>> actual DTD used by V3-there isn't one.
> We've been using the DTD for historical purposes (I presume, I came
> late to this effort). It would make sense, if we're truly ditching
> the DTD/schema (which i'm not sure I agree with) to use javadoc
> instead. It'd certainly make refactoring the locations of these
> elements easier. I've been trying to keep the java code for the
> grizzly end in sync but haven't done much for the glassfish end of
> things as it would mean breaking my glassfish working area. I'm
> doing that now, though, since we'll need it soon enough anyway.
There is no provision in V3 for a DTD as the source of the interfaces.
Java interfaces are the source at this point, the @Configured
interfaces. A DTD does not work for a pluggable system; it would have
infinite variation, never a fixed thing.
>
>>
>> llc02 -- Is it true we're deprecating and leaving the old http-
>> service stuff in place? I thought we would convert domain.xml.
>> Supporting old or new structure is awkward in a number of ways.
>> Just confirming here.
> Yes, a skeleton http-service will be left in place though it was
> recommended that it be renamed to web-container instead. I haven't
> heard any pushback on that idea so I'll do that now.
Messy, I'd push back personally.
>
>>
>> llc03 -- Exported interfaces: "Evolving" is no longer appropriate:
>> Committed is what we should use. Also, the description says
>> nothing about sub-elements, that should be clarified. And a DTD
>> cannot be the interfaces as we don't have one! The interface is
>> the Java interfaces.
> I've changed that and am generating those interfaces now as I
> mentioned above.
>>
>> llc04 -- Exported interfaces: all properties (their names and
>> legal values) are also interfaces, just as attributes are.
>> Property names and legal values spelled out. I see that some
>> properties from V2 are now first-class attributes, great!
>>
>> llc05 -- I think you should strip non-relevant stuff out of the
>> sample domain.xml; it confuses the description with extraneous
>> items. The "relevant changed portions" is all we need, but that
>> should show all possible attributes and properties for completeness.
> Bill wanted to see what things would look like under the new schema
> hence the domain.xml so that the changes can be seen in context. As
> for all possible values, etc, he wanted a minimal example so people
> wouldn't have to sift through too much. So I'm not sure which to
> give other than what we have there now.
The whole thing is fine, but inserting it right into the middle of the
spec is confusing, make it an appendix if you want to keep it.
>
>>
>> llc06 -- Please spell out what the legal values are (numbers, fixed
>> values, etc), and this should be javadoc'd as well. Legal values
>> are part of the interface, very important.
>>
>> llc07 -- Nit: I think "in" can safely by skipped eg "send-buffer-
>> size-bytes" vs "send-buffer-size-in-bytes", "timeout-seconds"
>> instead of "timeout-in-seconds", etc.
> I'll update this when I sync up the java interfaces. With a DTD
> it's easy enough to link to it from the one pager. How would you
> like to see the javadoc published?
We will need a special maven build step to collect all the javadoc for
all interfaces somehow. In the meantime a link from the spec would work.
>
>>
>> llc08 -- Disposition? "this value currently gets pushed to a
>> static method. shouldn't this belong on network-listeners instead"
> I've updated this, too, to reflect that this value will not be
> global anymore. Since it's no longer property driven, it's possible
> to set targeted, specific values where needed.
>>
>> llc09 -- AMX MBeans should be mentioned. Ideally the Java
>> interfaces would be shown here.
> the AMX MBeans pieces are still dark voodoo for me so if anyone
> *really* wants to see those, I'll need some help with that. There
> had been some talk about the AMX stuff being ... phased out going
> forward. I'm not sure of the details or the resolution of that one
> so if anyone knows something, I for one wouldn't mind an update.
Config MBeans are taken care of automatically by the AMX system, and
AMX is moving to a generic system. AMX interfaces aren't actually
required, but can be desirable for client convenience. At this point,
a note about AMX should suffice. If AMX is being phased out, it's news
to me!
>
>>
>>
>> Lloyd
>>
>>
>> On Jan 23, 2009, at 8:18 AM, Justin Lee wrote:
>>
>>> And for reference, the one pager is here: http://is.gd/c0ui
>>>
>>> Justin Lee wrote:
>>>> I've updated the xml examples on the one pager and they should
>>>> now reflect the current thinking on the schema changes. If you
>>>> see anything in the next 45 minutes that needs attention, please
>>>> don't hesitate to say anything. :) Thanks.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>