On Jan 18, 2008, at 12:27 PM, Lloyd L Chambers wrote:
> Jerome,
>
> My first comment is that the behavior in such situations must be
> *defined* (not undefined).
right, which is what we are trying to do now...
>
>
> My second comment is the name should be defined (you've now
> explained that the name is the name of the variable, but that isn't
> javadoc'd and I didn't know that--I thought it was by classname!).
so far, it's neither one of them so the implementation/javadoc should
be done once we have decided the behavious
>
>
> My third commend is that if an explicit name is not required, then
> the name should have more scoping than just the variable name alone.
> Consider the following class:
>
> package com.sun.Bar;
> @Service public class BarImplA {
> @Extract final MBeanServer mbeanServer = ...;
> public BarImplA() {}
> }
>
> If I understand correctly, the implicit name is "mbeanServer". I
> don't like using the variable name for the public name personally;
> it couples the public API (name) to the internal variable too
> closely. Maybe that's fine for prototyping but not for public APIs.
>
> So far an implicit name I was at least expecting something like
> "com.sun.Bar.mbeanServer". But I think something like this would be
> better in terms of clarity and decoupling:
> @Service public class BarImplA implements BarService {
> @Extract("BarService_MBeanServer") final MBeanServer mbeanServer
> = ...;
> public BarImplA() {}
> }
>
ok I think it would be ok yes, we then make name() a mandatory
attribute of the @Extract annotation. anyone else want to comment
before we commit ?
jerome
>
> Lloyd
>
> On Jan 18, 2008, at 12:14 PM, Jerome Dochez wrote:
>
>> I think extraction will work or at least should... now the real
>> problem is later, with injection....
>>
>> say you have
>> @Inject
>> MBeanServer foo;
>>
>> which one are u supposed to get ?
>>
>> Maybe we should force the @Extract to have name property (or use
>> the field name by default) so that extracted resources are always
>> stored in the habitat with a name.
>>
>> With your example the second extraction would fail since there is
>> already a MBeanServer nammed mBeanServer in the habitat. Seems like
>> predictable behaviour.
>>
>> comment ?
>>
>>
>> On Jan 18, 2008, at 11:58 AM, Lloyd L Chambers wrote:
>>
>>> Sahoo,
>>>
>>> Thanks.
>>>
>>> What happens when two things @Extract the same variable? Isn't
>>> this setting what amounts to an global variable in the Habitat?
>>> Is there an error produced, or does one variable just overwrite
>>> the other?
>>>
>>> What if I ran two versions of a Service at the same time, or two
>>> Services that both want to export a variable of the same class?
>>> From what I understand, using an un-named @Extract seems to invite
>>> problems.
>>>
>>> @Service public class BarImplA {
>>> @Extract final MBeanServer mbeanServer = ...;
>>> public BarImplA() {}
>>> }
>>>
>>> @Service public class BarImplB {
>>> @Extract final MBeanServer mbeanServer = ...;
>>> public BarImplB() {}
>>> }
>>>
>>> And of course I remain uneasy about @Inject thread safety, but
>>> perhaps the implementation does something about.
>>>
>>> Lloyd
>>>
>>> On Jan 17, 2008, at 8:03 PM, Sahoo wrote:
>>>
>>>> Lloyd L Chambers wrote:
>>>>> Kosuke et al,
>>>>>
>>>>> [I think these comments/questions are relevant to other
>>>>> developers...let's answer them, and I can help updating javadoc,
>>>>> etc once I'm sure I understand it]
>>>>>
>>>>> I'm still learning annotations, so I don't "get" the javadoc for
>>>>> @Extract and @Inject.
>>>>>
>>>>> Suggestion: there should be examples in the javadoc showing how
>>>>> to use the annotations.
>>>>>
>>>>> For example, the Javadoc (https://hk2.dev.java.net/nonav/auto-depends/apidocs/org/jvnet/hk2/annotations/Extract.html
>>>>> ) doesn't tell me anything really about how to use @Extract
>>>>> ("Annotation marks instances of object which are labeled as
>>>>> exported by a component"):
>>>>>
>>>>> 1. Exported to where?
>>>> Exported to the component registry (a.k.a. Habitat in HK2).
>>>>> 2. Under what name?
>>>> Unless you specify a name in @Extract, it is an unnamed object.
>>>>> What is the naming convention?
>>>> Any string
>>>>> 3. What do I write to @Inject it? What happens if it's not yet
>>>>> available?
>>>>>
>>>> Let's take an example:
>>>>
>>>> @Service public class BarImpl implements PostConstruct {
>>>> @Extract BazImpl baz;
>>>> public BarImpl() {System.out.println("BarImpl()");}
>>>> public void postConstruct() {baz = new BazImpl();}
>>>> }
>>>>
>>>> public class BazImpl {
>>>> public BazImpl() { System.out.println("BazImpl()");}
>>>> }
>>>>
>>>> @Service public class Foo implements ModuleStartup {
>>>> @Inject Habitat habitat;
>>>> @Inject BarImpl bar;
>>>>
>>>> public void setStartupContext(StartupContext context) {}
>>>>
>>>> public void run() {
>>>> System.out.println(bar.baz);
>>>> System.out.println(habitat.getComponent(BazImpl.class));
>>>> }
>>>> }
>>>>
>>>> When you run it using mvn hk2:run, you shall see something like
>>>> this:
>>>> BarImpl()
>>>> BazImpl()
>>>> sahoo.hk2test4.BazImpl_at_b3319f
>>>> sahoo.hk2test4.BazImpl_at_b3319f
>>>>
>>>> The point worth noting is that BazImpl() is called only once and
>>>> habitat.getComponent(BazImpl.class) returned the same instance as
>>>> pointed to by bar.baz.
>>>>
>>>> Note that, we need not mark BazImpl as a @Service, although in
>>>> many cases it may itself be a service. I think there is some work
>>>> to be in HK2 about @Extract processing, as it currently only
>>>> exports the object under the type name of the implementation
>>>> class (in this case BazImpl.class).
>>>>
>>>> Yes, we plan to add some examples to the documents soon.
>>>> Thanks,
>>>> Sahoo
>>>>> ---
>>>>> Lloyd L Chambers
>>>>> lloyd.chambers_at_sun.com <mailto: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
>>>>
>>>
>>> ---
>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>