Thanks Jim, Raymond, I realize there are some fine points to deal with here and wasn't sure what to do next. I think this is better in the meantime (and spec-compliant though the spec could use some clarity).
Scott On 2/12/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Yes, I committed the changes to trunk as well. Thanks, Raymond ----- Original Message ----- From: "Jim Marino" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, February 12, 2007 12:09 PM Subject: Re: Bug in deriving the service name from a java interface? > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
