atom feed24 messages in net.java.dev.glassfish.adminRe: Comments on grizzly config one pager
FromSent OnAttachments
Justin LeeJan 23, 2009 8:16 am 
Justin LeeJan 23, 2009 8:17 am 
Oleksiy StashokJan 23, 2009 8:45 am 
Lloyd ChambersJan 27, 2009 12:56 pm 
Justin LeeJan 28, 2009 7:41 am 
Lloyd ChambersJan 29, 2009 10:58 am 
Justin LeeJan 29, 2009 1:01 pm 
Justin LeeJan 30, 2009 12:09 pm 
Lloyd ChambersJan 30, 2009 3:32 pm 
Lloyd ChambersJan 30, 2009 3:40 pm 
Kedar MhaswadeJan 30, 2009 3:46 pm 
June...@Sun.COMJan 30, 2009 3:51 pm 
Kedar MhaswadeJan 30, 2009 3:54 pm 
Lloyd ChambersJan 30, 2009 3:55 pm 
Kedar MhaswadeJan 30, 2009 4:40 pm 
Justin LeeJan 30, 2009 5:04 pm 
Jerome DochezFeb 2, 2009 9:20 am 
Kedar MhaswadeFeb 2, 2009 10:53 am 
Jerome DochezFeb 2, 2009 11:22 am 
Kedar MhaswadeFeb 2, 2009 2:15 pm 
Tim QuinnFeb 2, 2009 3:05 pm 
Kedar MhaswadeFeb 2, 2009 3:17 pm 
Jerome DochezFeb 3, 2009 12:50 pm 
Kedar MhaswadeFeb 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
List:net.java.dev.glassfish.admin

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!

On Jan 23, 2009, at 8:18 AM, Justin Lee wrote:

And for reference, the one pager is here: http://is.gd/c0ui

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.