Justin,
Seems more approachable now, thanks!
Too bad the javadoc can't be "live" instead of a jar-file attachment.
A wiki limitation I guess.
I notice one issue right away:
why not just a getter and setter? enableCometSupport();
mis-spelled: setEnableCommetSupport();
missing: getEnableCometSupport();
Other:
- for items like Forced response type, an example would be very
helpful over and above "Specified as a semi-colon delimited string
consisting of content-type, encoding, language, charset".
- PropertyBag exists in HK2 are we duplicating it intentionally for
grizzly so it can be standalone?
Thanks,
Lloyd
..............................................
Lloyd Chambers
GlassFish team, LSARC member
On Jan 30, 2009, at 12:10 PM, Justin Lee wrote:
> I'm "done" with the updates, I think. I have the grizzly
> interfaces done and have attached the javadoc to the one pager. I
> left the DTDs linked in case anyone was overly attached to having
> them. I haven't modified the glassfish interfaces yet since the
> impact there is much wider but if anyone's interested, I can do
> that, too.
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=GrizzlyConfigOnePager
>
> Justin Lee wrote:
>> Lloyd Chambers wrote:
>>> Jason,
>>>
>>> Thanks...response inline.
>>>
>>> Lloyd
>>>
>>> On Jan 28, 2009, at 7:41 AM, Justin Lee wrote:
>>>
>>> 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.
>>>
>> I'm actually in the process of making sure the DTD(s) and the
>> interfaces are in sync and then I'll probably just remove the DTDs
>> for good measure and work from the interfaces. I'm debating
>> writing an hk2/maven mojo to generate a DTD/XSD for basic
>> validation (largely for my own benefit).
>>
>>>> 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.
>>>
>> We had debated removing it completely and migrating the remaining
>> elements elsewhere. I have no strong feelings either way.
>>
>>> 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.
>> I can move this out if you'd like. It's already in the grizzly
>> repo, so I can just link to it. That's how it was originally,
>> anyway.
>>> 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.
>>>
>> This is why I'm thinking about that maven plugin, actually...
>>>>
>>>>>
>>>>> 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
>> Anyone have anything to add here?
>>> 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!
>> It's all news to me at this point. :)
>>
>> Thanks for the feedback, though. I'm trying to get it all together
>> for you to see as soon as possible.