Hi Raymond
O.K. Thanks. Is this against trunk?
Jim
On Feb 12, 2007, at 11:57 AM, Raymond Feng wrote:
Hi, Jim.
I'll commit a change to use simple names for now and we can deal
with the conflicting cases later.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, February 09, 2007 4:00 PM
Subject: Re: Bug in deriving the service name from a java interface?
On Feb 9, 2007, at 2:32 PM, Scott Kurz wrote:
Hi,
I was just looking back on this thread and wondering where we
ended up.
Did the Java C&I spec and/or any IRC discussions add some
clarity here?
It seems a shame to lose the simple syntax in the more common
case to
support the strange case where the service name really needs pkg
qualification. It's probably too late to point this out but
the spec could
deal with this by saying that in this edge case the default
service name
includes pkg qualification while in the more typical case the
service name
is calculated as the unqualified intf name.
I haven't forgot but we've been dealing with so many other spec
issues, including the API changes, that I figured we would deal
with this in the 1.1 version of the specs. I think the solution
you outlined is good (i.e. default to the simple name when
possible) and in the case where there is more than one simple
name, either use the fully qualified name or allow an annotation
to specify an alias.
I wonder if everyone is using single-service components and
bypassing this
issue...
No I think multiple services will be common enough we should
support something per the above. If you're interested in working
on a patch, I'd be happy to help if needed.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
