dev@glassfish.java.net

Re: _at_ConfiguredBy implemented?

From: Ludovic Champenois <ludovic.champenois_at_oracle.com>
Date: Thu, 01 Jul 2010 12:36:12 -0700

On 7/1/10 12:23 PM, Justin Lee wrote:
> grizzly-config defines a number of such beans that live neither in
> that package nor in the glassfish tree and I'm not using
> @ConifiguredBy either. The commands that manipulate the domain.xml do
> but only because grizzly itself doesn't use asadmin. I don't know
> that you really need @ConfiguredBy at all unless you're doing
> something really exotic. You should just be able to bundle them as an
> osgi bundle and drop it into glassfish.

correct, as long as your module can depend on HK2, you can define new
configbeans in your module outside of GlassFish.
JRuby/Rails also does it and it developed outside the GF repo:
see
https://glassfish-scripting.dev.java.net/source/browse/glassfish-scripting/trunk/rails/config/src/main/java/org/glassfish/scripting/jruby/config/

Our REST admin backend can discover these configbeans via HK2, if the
module is installed under modules/ directory.
Ludo


>
> On 7/1/10 3:14 PM, Chris Kasso wrote:
>> I am developing a module that will *not* be included in the open source
>> edition of GlassFish. The module introduces some new commands as
>> well as some config to be maintained in the domain.xml. The
>> class/interface
>> which implements the ConfigBeanProxy will not live in the
>> com.sun.enterprise.config.serverbeans package.
>>
>> The little bit of documentation I found implies I can use @ConfiguredBy
>> to point to the class that provides the configuration for the
>> configuration consumer. But when I inject the config I'm seeing
>> an org.jvnet.hk2.component.UnsatisfiedDependencyException.
>>
>> Looking at the HK2 docs for @ConfiguredBy:
>>
>> http://javadoc.glassfish.org/v3/apidoc/org/jvnet/hk2/config/ConfiguredBy.html
>>
>>
>> there is a comment: ``TODO: still a work in progress''
>>
>> This suggests @ConfiguredBy is not fully baked.
>>
>> I've not been able to find any working examples either.
>>
>> Should I be going down this path or is there a different approach I
>> should
>> consider (e.g. ship the config bean as part of
>> com.sun.enterprise.config.serverbeans)?
>>