On 7/1/10 3:33 PM, Chris Kasso wrote:
>
> My module is installed under the modules/ directory (and the command
> defined by that module works in asadmin). But I'm not sure how to
> access the configbean from within the command.
>
> The scenario is pretty simple. FooCommand.java implements
> AdminCommand and injects:
>
> @Inject
> FooConfig config;
>
> FooConfig is a basic configbean:
>
> @Configured
> public interface FooConfig extends ConfigBeanProxy, Injectable,
> PropertyBag {...}
>
> But running the command generates:
>
> Unsatisfied dependency exception :
> com.sun.glassfish.dasrecovery.FooConfig
> com.sun.glassfish.dasrecovery.FooCommand.config
>
> [#|2010-07-01T15:11:25.417-0700|INFO|glassfish3.1|null|_ThreadID=23;_ThreadName=http-thread-pool-4848(1);|Cannot
> inject com.sun.glassfish.dasrecovery.FooConfig
> com.sun.glassfish.dasrecovery.FooCommand.config in component
> com.sun.glassfish.dasrecovery.FooCommand_at_716387|#]
> [#|2010-07-01T15:11:25.420-0700|SEVERE|glassfish3.1|null|_ThreadID=23;_ThreadName=http-thread-pool-4848(1);|org.jvnet.hk2.component.UnsatisfiedDependencyException:
> Unsatisfied dependency exception :
> com.sun.glassfish.dasrecovery.FooConfig
> com.sun.glassfish.dasrecovery.FooCommand.config|#]
>
> Note that in the implementation I'm not injecting Config because
> FooConfig is not a child of <config>. It is a peer to <config>.
ok but do you have a <foo-config> element defined in your domain.xml ?
Also, is it added to the parent Configs.java ?
>
> Somewhat related question: If I wanted <foo-config> to be a child of
> <config> in domain.xml how does one do that given Foo is a plugin to
> GF (let's pretend I can't modify Config.java to add the FooConfig
> accessor methods.)
you can't. it's typed. the only way is to use a generic type in the
parent, for instance
public interface Parent {
List<Child> children();
}
public interface ChildA extends Child {}
public interface ChildB extends Child {}
anyone can then come up with a Child subtype and get plugged in Parent
automatically.
jerome
>
> Chris
>
> Ludovic Champenois wrote:
>> 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)?
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>