An injection wiring scenario

[starksm64]

Do we have all the pieces in place for this scenario:

- A named pojo instance (in its most strict form this could be a singleton) that has two Properties maps attributes
+ The pojo has methods to manipulating the Properties contents
+ The pojo has these methods exposed via JMX

- Another pojo needs the named pojo instance Properties maps injected to function correctly. This pojo only has a default ctor, and the only point for injecting the Properties maps is this initialize method:

 public void initialize(Subject subject, CallbackHandler callbackHandler,
 Map sharedState, Map options)

The Properties should be found in the options argument under the keys "users" and "roles". However, by the time the initialize method is called, the options Map is a read-only object.

Do we have a framework that can acomplish this wiring yet?

[adrian.brock]

Do we have all the pieces in place for this scenario:

- A named pojo instance (in its most strict form this could be a singleton) that has two Properties maps attributes
+ The pojo has methods to manipulating the Properties contents
+ The pojo has these methods exposed via JMX

Yes

- Another pojo needs the named pojo instance Properties maps injected to function correctly. This pojo only has a default ctor, and the only point for injecting the Properties maps is this initialize method:

 public void initialize(Subject subject, CallbackHandler callbackHandler,
 Map sharedState, Map options)

The Properties should be found in the options argument under the keys "users" and "roles". However, by the time the initialize method is called, the options Map is a read-only object.

Do we have a framework that can acomplish this wiring yet?

No. Do we really want to support an xml scripting language in the configuration?

Complicated/Programmatic config like this can be handled by "lifecycle advices".
I'd guess in this case it would be "create"? But it could also be
construction or any other joinpoint.

i.e.
advice depends upon properties (or named pojo)
"another" depends upon advice

[starksm64]

By wiring I did not mean that it had to be strictly via configuration level constructs between the two pojos. There actually is a natural point for joining these before having to deal with the initialize() method. The usecase here is a login configuration with a login module that may take its options from a static configuration, or injection of another object's attributes.

static:

 <application-policy name="testXMLLoginModule">
 <authentication>
 <login-module code="SomeLoginModule" flag="required">
 <module-option name="users">
 <lm:users xmlns:lm="urn:jboss:jaas">
 <lm:user name="user1" password="pass1" />
 <lm:user name="user2" password="pass2" />
 </lm:users>
 </module-option>
 <module-option name="roles">
 <lm:roles xmlns:lm="urn:jboss:jaas">
 <lm:user name="user1">
 <lm:role name="Role1"/>
 <lm:role name="Role2"/>
 <lm:role name="callerJduke" group="CallerPrincipal" />
 </lm:user>
 </lm:users>
 </module-option>
...

injection:

 <application-policy name="testXMLLoginModule2">
 <authentication>
 <login-module code="SomeLoginModule" flag="required">
 <module-option name="users">
 <depends name="PropertiesSource" property="Users" />
 </module-option>
 <module-option name="roles">
 <depends name="PropertiesSource" property="Roles" />
 </module-option>
...

[adrian.brock]

Ok, so you just want to inject a bean's property rather than the bean value.

The only way this could be done with the current metadata model would
be to put a dummy factory inbetween that did the getting.

But this seems such a trivial usecase that I don't see why it could not be supported
directly.

In MC XML (note the property attribute is what we are talking about and is not currently supported)

<property name="roles">
 <inject bean="PropertiesSource" property="roles" />
</property>

Whether we want to go further into xml scripting is another issue, e.g.

 <inject bean="PropertiesSource" script="getRoles().toString()" />
 <inject bean="PropertiesSource" script="getRoles().get("Value1"))" />
 // transient property PropertiesSource.getRoles().getSize()
 <inject bean="PropertiesSource" property="roles.size" />
 etc.

Including "abitrary" initialize methods could also be supported
with something like

 <depends>
 <create method="initialize">
 <parameter><inject bean="PropertiesSource" property="roles"/></parameter>
 </create>

One problem with the latter (besides it fails the 95%/5% use case rule)
is that the annotation version requires parameter annotations
(although it isn't something you want to do in this case :-)

@CreateLifecycle
public void initialize(
@Inject(bean="PropertiesSource", property="users")
Map users,
@Inject(bean="PropertiesSource", property="roles")
Map roles
)
{
// Do it
}

[adrian.brock]

I'd only anticapted supporting lifecycle methods with no arguments.

[adrian.brock]

I just added support for the property injection, passing parameters in lifecycle operations
will come soon...

Commit message:

Add support for injecting a property of a bean rather than a bean,
 e.g.
 <bean name="MyService" class="MyClass">
 <property name="transactionManager">
 <inject bean="TransactionManagerService" property="instance"/>
 </property>
 </bean>
 or
 MyClass.setTransactionManager(TransactionManagerService.getInstance());

 This also works anywhere there is an injection, i.e. properties, factories,
 parameters, collections, etc.

[adrian.brock]

The ability to override lifecycle methods is now supported.

e.g. rather than doing

<bean>
 <depends>SomeName</depends>
</bean>

You can now do

public void initialize(SomeBean bean)
{
// etc.
}
<bean>
 <create method="initialize">
 <parameter><inject bean="SomeName"></parameter>
 </create>
</bean>

Of course, other parameters such as plain values, collections, bean properties
are also supported.