Jerome,
My first comment is that the behavior in such situations must be
*defined* (not undefined).
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!).
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() {}
}
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