On Jan 18, 2008, at 11:31 AM, Lloyd L Chambers wrote:
> I've experienced the same unease that Kedar expresses (but in
> regards to other design issues). For us admin folks starting work
> on V3, surprises in the admin area are doubly disconcerting, but
> since most of the admin team is just starting work on V3, surprises
> and confusion are inevitable. The admin team has to take up its
> areas at whatever point they stand now (which includes the
> responsibility for reversing and/or changing any existing V3 admin-
> related decisions if there is good reason).
>
> At its heart, this email exchange is symptomatic of a key challenge
> that needs to be dealt with — communicating the current assumptions
> and intent of the very small team that engendered V3 to a broader
> audience of developers. We need mechanisms for that to happen, and
> be hallway conversations or even weekly meetings do not suffice (as
> useful as those are). (It's a very interesting challenge about how
> to built these processes).
>
> I note that the email exchange began as a factual exchange, which is
> good. But consider the *context* — an internal developer, indeed
> the lead for the admin area, is surprised by the behavior of V3 with
> respect to an admin-related feature! That's a fact which should be
> understood dispassionately, but also taken as a call to action.
>
> So here are my thoughts on where we can improve:
>
> 1. Expectations -- We need a “state of the server” page, a sort of
> combined FAQ and "TO DO" page which makes explicit what's done,
> what's in progress and what remains to do. this is not a schedule
> per se, but rather something to set expectations.
>
> For example, I know where the AMX (MBean API) code stands, but
> hardly anyone else does. Where should I describe my plan, vision
> and current status for that area? Presumably under some admin page
> on our web site somewhere. But I don't know where that is. I have
> written up a number of documents which I previously sent out, but
> there is no "status page" for AMX as yet.
yes you should start an admin page on the wiki and start a link to AMX
work from there. I think the wiki is the right combination of editing
and sharing combination we would need to sustain such documentation. I
would encourage everyone working on V3 to do the same, I think it is a
great idea and very necessary, we need something from
- Kedar (Admin in general)
- Lloyd (AMX)
- Hong (Deployment)
- Amy (Webtier)
- Jane (CLI)
- GUI (Ken)
>
>
> 2. Documentation -- at a minimum, the Javadoc for HK2 and V3 APIs
> needs to be seen as fundamental to bringing developers on board with
> HK2 and V3. It's currently extremely terse, of use only to those
> who have read and understood the code (and hence of no real use!).
> I intend to help in this area, but in truth developers of APIs must
> take responsibility for writing javadoc that is clear and helpful to
> "newbies". It looks bad to have mis-spelled gramattically incorrect
> and just plain confusing javadoc for our product. I intend to help
> in that way too, but the writer of the API bears the responsibility.
I agree but of course, reality bites.
>
>
> 3. Email -- email exchanges like this one have low residual value.
> We need to move these discussions to web pages so that value
> accumulates instead of dissipating.
that's one of the positive of using the dev@ mailing lists. there is
automatic archival. Wouldn't that suffice ?
>
>
> 4. Wiki pages: I do like Wikis so long as I don't have to *edit*
> them (tedious and awkward for larger pages, and wasn't WYSIWYG
> invented 20 years ago?). So we need to think hard about what is
> easy to edit and maintain. Perhaps a mix of Wiki and HTML will
> work, but I don't understand how to mix them well.
well, you would need to come up with a proposal here. I agree that
wiki editing is a bit too close to latex and just like maven. It has
deficiencies but until there is a viable replacement, I think we need
to stick with it...
>
>
> Lloyd
>
> On Jan 18, 2008, at 10:43 AM, Jerome Dochez wrote:
>
>>
>> On Jan 18, 2008, at 10:22 AM, Kedar Mhaswade wrote:
>>
>>>
>>>
>>> Bill Shannon wrote:
>>>> Kedar Mhaswade wrote:
>>>>>
>>>>>
>>>>> Ludovic Champenois wrote:
>>>>>> Kedar Mhaswade wrote:
>>>>>>> OK, I built V3 and then started the domain fine. I see that
>>>>>>> Grizzly comes up fine at port 8080. Then I deploy a war file
>>>>>>> like:
>>>>>>>
>>>>>>> "asadmin deploy --port 8080 foo.war", which successfully
>>>>>>> deploys.
>>>>>>>
>>>>>>> So, does it mean that the administrative commands are handled by
>>>>>>> the Grizzly listener at 8080, where user applications are
>>>>>>> deployed?
>>>>>>>
>>>>>>> Is this by design, or we are in process of directing asadmin
>>>>>>> commands
>>>>>>> to a separate Grizzly listener (usually at 4848, like we do
>>>>>>> for V2)?
>>>>>>>
>>>>>>>
>>>>>>> Dazed and Confused in Santa Clara :)
>>>>>> Why?
>>>>>> The admin area work needs to start on V3:). Welcome aboard.
>>>>>> For now, 1 single port is the easy workaround (and as a
>>>>>> developer, I don't mind simple things in the current prototype/
>>>>>> implementation: no need to understand username/password or
>>>>>> master password in the current V3).
>>>>>> Ludo
>>>>>
>>>>> It's just that it is not mentioned anywhere. I don't disagree
>>>>> with the intent,
>>>>> but it has to be made explicit. Sorry, I am not used to doing
>>>>> things in
>>>>> ad hoc manner.
>>>>>
>>>>> Having no user name and password (master password is not used in
>>>>> this case at
>>>>> all, FYI) is OK in certain cases, but not all.
>>>>>
>>>>> Also, the domain.xml has the lines
>>>>> <http-listener id="admin-listener" address="0.0.0.0"
>>>>> port="4848" acceptor-threads="1" security-enabled="false"
>>>>> default-virtual-server="__asadmin" server-name="" xpowered-
>>>>> by="true" enabled="true" family="inet" blocking-enabled="false"/>
>>>>>
>>>>>
>>>>> What are they for?
>>>>> What's the use of __asadmin virtual server? Why is it there in
>>>>> domain.xml by
>>>>> default when it is not used.
>>>>>
>>>>> Sorry Ludo, this needs to be thought through.
>>>> Maybe you should just assume it's not yet implemented and finish
>>>> it.
>>>> Well, ok, "assume" is the wrong word. After checking with Jerome
>>>> to
>>>> confirm that it's simply a case of that functionality having not
>>>> been
>>>> implemented yet, go ahead and finish it.
>>>
>>> I don't understand this mode of operation. But I will bite the
>>> bullet
>>> and do as expected. I am just surprised that this kind of
>>> exception is not
>>> surprising to you.
>> what exactly do you not understand ? That we cannot come up with a
>> new Appserver implementation overnight ?
>> If nothing has been decided, that mean we should have backward
>> compatibility, or status quo. If this is not the case today, it's
>> because it's not done or finished.
>>
>>>
>>>
>>> One of my basic problems is to know what is "done" and what is
>>> isn't. Maybe it was just decided that we don't need a separate
>>> listener
>>> and VS for admin operations and I was just trying to understand if
>>> it
>>> were the interim decision.
>> that's fine. It is hard to know what is "done" I have to agree.
>> Again, if this was not discussed, consider that it does not have to
>> be changed so your assumption should be that this need more work.
>>
>>>
>>>
>>> I believe sending an e-mail to dev alias is equivalent to checking
>>> with
>>> Jerome. Do you disagree?
>>
>> I don't.
>>>
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>