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.
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.
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.
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.
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