|Justin Lee||Jan 23, 2009 8:16 am|
|Justin Lee||Jan 23, 2009 8:17 am|
|Oleksiy Stashok||Jan 23, 2009 8:45 am|
|Lloyd Chambers||Jan 27, 2009 12:56 pm|
|Justin Lee||Jan 28, 2009 7:41 am|
|Lloyd Chambers||Jan 29, 2009 10:58 am|
|Justin Lee||Jan 29, 2009 1:01 pm|
|Justin Lee||Jan 30, 2009 12:09 pm|
|Lloyd Chambers||Jan 30, 2009 3:32 pm|
|Lloyd Chambers||Jan 30, 2009 3:40 pm|
|Kedar Mhaswade||Jan 30, 2009 3:46 pm|
|June...@Sun.COM||Jan 30, 2009 3:51 pm|
|Kedar Mhaswade||Jan 30, 2009 3:54 pm|
|Lloyd Chambers||Jan 30, 2009 3:55 pm|
|Kedar Mhaswade||Jan 30, 2009 4:40 pm|
|Justin Lee||Jan 30, 2009 5:04 pm|
|Jerome Dochez||Feb 2, 2009 9:20 am|
|Kedar Mhaswade||Feb 2, 2009 10:53 am|
|Jerome Dochez||Feb 2, 2009 11:22 am|
|Kedar Mhaswade||Feb 2, 2009 2:15 pm|
|Tim Quinn||Feb 2, 2009 3:05 pm|
|Kedar Mhaswade||Feb 2, 2009 3:17 pm|
|Jerome Dochez||Feb 3, 2009 12:50 pm|
|Kedar Mhaswade||Feb 3, 2009 1:19 pm|
|Subject:||Re: Comments on grizzly config one pager|
|From:||Lloyd Chambers (Lloy...@Sun.COM)|
|Date:||Jan 29, 2009 10:58:29 am|
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!
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.