OnDemand as an aspect

[alesj]

Thinking about his more + reading existing jboss-dev ml entries,
I think we need much more transparent "On_Demand" integration.

e.g. if some service wants to be an entry point of "igniting" On_Demand beans
it needs to implement certain MC On_Demand mechanism

 ControllerContext context = controller.getContext(name, null);
 if (context == null)
 throw new IllegalArgumentException("No such context: " + name);

 controller.enableOnDemand(context);
 controller.change(context, ControllerState.INSTALLED);

 if (ControllerState.INSTALLED.equals(context.getState()) == false)
 throw new IllegalArgumentException("Couldn't fully install service: " + context);

 delegate = (SomeBean)context.getTarget();

And this is _very_ invasive.

A natural solution is probably the usage of AOP aspects.
We should be able to describe the service's need for such On_Demand beans
via ctor, method or field interceptor.
e.g.

@OnDemand(beans = {"TransactionManager", "ThreadPool"})
public void someMethod(int x)
{
 ...
}

Having only such beans array value is probably too static,
we would want to introduce much more dynamic behavior.
e.g. @OnDemand(factory = SomeDynamicOnDemandFactory.class)
Or grabbing some info out of the invoked Member itself.

Then these AOP aspect would hide the MC mechanism,
with the user only having to annotate his bean,
either in xml or directly on the class.

[dmlloyd]

What's the use case? My impression was that last time the topic of on-demand beans came up, we didn't want to use them this way because it would cause e.g. the first request which uses the bean to do all the dirty work, which isn't useful for most cases (it only provides the illusion of a quick startup).

To me it makes more sense to restrict our usage of on-demand beans to deployments that are only activated if a user deployment consumes it declaratively (in other words, beans depend on beans; methods do not depend on beans).

Also, and I only speak for myself here, I'm personally really hesitant to invest more into AOP, given that AOP appears to be at least one key source of the performance problems that we have right now.

[ccrouch]

What's the use case? My impression was that last time the topic of on-demand beans came up, we didn't want to use them this way because it would cause e.g. the first request which uses the bean to do all the dirty work, which isn't useful for most cases (it only provides the illusion of a quick startup).

We had/have exactly this use case with the Embedded Console in JBAS5.1.CR1. In order to start the Embedded Console you need to, amongst other things, initialize Seam and have it scan the console .war, and then run a scan of the JBAS instance looking for whats deployed. Right now those two things are taking around 20seconds to execute iirc. There is certainly some optimization that could be done here, but we're never going to get those things down to say 1second. Therefore it makes sense on app server startup not to penalize people who aren't going to use the console with the time costs of starting it up. So given this on-demand deployment isnt supported right now we hacked around it with a web filter and listener that delayed the Seam bootstrap and scanning until the first request to a page. If we had the ability to mark the deployment as on-demand we wouldn't have needed to do this.

Cheers

[dmlloyd]

Perhaps a more sane solution is to have a lazy servlet initialization function in JBossWeb. I don't think this is a "healthy" general-purpose solution, because the patterns it encourages are almost never desirable. For example, you only describe using it as a workaround for another problem.

[jason.greene]

To me it makes more sense to restrict our usage of on-demand beans to deployments that are only activated if a user deployment consumes it declaratively (in other words, beans depend on beans; methods do not depend on beans).

Also, and I only speak for myself here, I'm personally really hesitant to invest more into AOP, given that AOP appears to be at least one key source of the performance problems that we have right now.

To do on-demand properly, we do need a first request activation mechanism. However, it seems like using an activation aspect is overkill. Why can't the API just be simplified, or better yet automated on first non-lifecycle MC method access.

[jason.greene]

Perhaps a more sane solution is to have a lazy servlet initialization function in JBossWeb. I don't think this is a "healthy" general-purpose solution, because the patterns it encourages are almost never desirable. For example, you only describe using it as a workaround for another problem.

The use case is development, and you are only working with 1 of the 300 apps you have "deployed".

[alesj]

What's the use case?

Any service that might be potential On_Demand activator.

e.g. let's say we have a cmd line console (which we do btw ;-))
I don't wanna instantiate all the stuff unless somebody actually uses it == connects to it's ssh SocketServer.
I would only install ssh deamon, while wrapping the Socket initalization logic
with MC's On_Demand activation mechanism.
This would then trigger full install of all other needed beans.

But this means my code must know MC,
no matter how simple we make the mechanism,
is still too intrusive and users will never wanna depend on MC api.
Which makes complete sense, as we always preach how transparent it should be to use IoC.

And any other service that would serve as an activatior would have to do the same,
which means a lot of copy/pasting, depending on the api that might even change (although it's a spi).

To me it makes more sense to restrict our usage of on-demand beans to deployments that are only activated if a user deployment consumes it declaratively (in other words, beans depend on beans; methods do not depend on beans).

That too.
But that's the job of a profile service.

Here we're talking fine grained stuff,
and ctor, method, field invocation makes a valid activation use case.

Also, and I only speak for myself here, I'm personally really hesitant to invest more into AOP, given that AOP appears to be at least one key source of the performance problems that we have right now.

Afaic this is not really investing into AOP, it's investing into aspects.
Or how else are you gonna make this transparent?

I doesn't need to be AOP at the end, if you're not calling dynamic proxies AOP.
We should provide a set of aspect, helpers, ... which could then be applied how ever the users want.

But with having tight AOP integration already in MC,
and it's not gonna go away any time soon,
we might as well provide this AOP based approach out-of-the-box.
Same way we do @JMX, @JndiBinding and Anil's @Password.

[alesj]

or better yet automated on first non-lifecycle MC method access.

How would you do that?

Which beans should be automated?
How would you know what to fully install (which beans to activate)?

You need extra info.
And annotations are a perfect fit.
Not to mention that "first access" screams for AOP interceptors. :-)

[jason.greene]

"alesj" wrote:

or better yet automated on first non-lifecycle MC method access.

How would you do that?

Which beans should be automated?
How would you know what to fully install (which beans to activate)?

You need extra info.
And annotations are a perfect fit.
Not to mention that "first access" screams for AOP interceptors. :-)

It definitely screams for proxies, not sure about all of the AOP baggage. :) What I meant was that you could express that pojo A has hard dependency on B, but A also has lazy dependency on C. Then when A is started, it gets a the normal ref to B, but a lazy proxy of C (non-start/activated). The first call on C triggers activation of C.

In addition, there could be some kind of lazy registry call to get a lazy ref to an MC service.

[alesj]

It definitely screams for proxies, not sure about all of the AOP baggage. :) What I meant was that you could express that pojo A has hard dependency on B, but A also has lazy dependency on C. Then when A is started, it gets a the normal ref to B, but a lazy proxy of C (non-start/activated). The first call on C triggers activation of C.

In addition, there could be some kind of lazy registry call to get a lazy ref to an MC service.

Actually this is all already there. :-)
See lazy element in MC schema.

I just need to properly finish On_Demand handling in these lazy wrappers.