Feature: MC Equivalent of @Service

[alrubinger]

Want to address a future feature and get a feel for how much work would be required.

We've currently got @Service, which deploys a Singleton EJB and exposes a JMX View. Oftentimes this is used strictly to get a hook into a Lifecycle (ie. "I want a callback for when my JAR is deployed"). And JMX exposure is not necessarily desired.

I'd like to introduce the notion of an MC EJB, which would have the following features:

* Full EJB (Tx, Security, etc)
* @Singleton (Same model following EJB3.1 with regards to concurrency)
* POJO w/ annotations to denote Callbacks (@Service requires Management interface)
* Proxy is installed into MC and therefore becomes a valid MC Bean; though when MC POJOs invoke on the EJB MC Bean, a typical EJB call starts.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
@Singleton (Same model following EJB3.1 with regards to concurrency)

Actually, it wouldn't need to be a Singleton at all. Just install a proxy into MC and it can be SLSB just as easily. SFSB wouldn't make much sense here.

S,
ALR

[alesj]

"ALRubinger" wrote:

We've currently got @Service, which deploys a Singleton EJB and exposes a JMX View. Oftentimes this is used strictly to get a hook into a Lifecycle (ie. "I want a callback for when my JAR is deployed"). And JMX exposure is not necessarily desired.

@Service ~ MC's @JMX
MC beans are 'singletons' in MC (not prototypes). And you can of course code it via factory instantiation to be 'real' singletons (one per CL ... dunno how you achieve that for VM though).

"ALRubinger" wrote:

I'd like to introduce the notion of an MC EJB, which would have the following features:

1) Full EJB (Tx, Security, etc)
2) @Singleton (Same model following EJB3.1 with regards to concurrency)
3) POJO w/ annotations to denote Callbacks (@Service requires Management interface)
4) Proxy is installed into MC and therefore becomes a valid MC Bean; though when MC POJOs invoke on the EJB MC Bean, a typical EJB call starts.

1) If you have matching aspects for it (@Tx --> Tx aspect, ...) this comes out-of-the-box in MC ... the bean will be aspectized - a JBossAop proxy.
Or you can install it into MC with already created instance, as we've discussed it before.
2) As explained above
3) Annotation handling is pluggable; e.g. ejb's @Create can be mapped to MC's create notion ... see how we handle MC's @Create
4) Sure, once it's in MC anyone can invoke it ... if the injection happens by name, then you might consider On_Demand mode.
Or perhaps my Lazy hack - we can discuss this further, if previous solutions don't work for you.

[alrubinger]

I'd like to focus on what we can get for free within EJB3.

Ales mentions a lot of MC-provided functionality for installing the EJB Implementation Class and adding onto it. I'm more thinking in terms of:

* New EJB Type (new Container), building upon either SessionContainer or StatelessContainer
* Install a Proxy to the EJB in MC, instead of in JNDI
* Add deployment-level Lifecycle Callbacks

So maybe the following:

@Stateless
@MC(name="MyBean")
public class MyMcBean implements MyMcLocalBusiness{...}

...is what this looks like, making a SLSB, installing the proxy into MC at "MyBean", and hooking the callbacks into MC's lifecycle mechanism.

S,
ALR

[wolfc]

You need to differentiate between EJB 3 and POJO Server.

POJO Server provides Tx, Security for any MC Bean. The only difference is the detached instances.

It's a misconception that a service bean requires a management interface. It's also a misconception that that management interface actually manages the container life cycle. It's a very basic chicken/egg problem. If I stop either chicken or egg, there will be no more eggs to start. (See also http://jira.jboss.org/jira/browse/EJBTHREE-655)

What is easily possible is a MC view on an EJB. This should not require any new container and should be applicable to both SLSB and Service/Singleton.

As for the actual life cycle callbacks, these are @PostConstruct and @PreDestroy.
Although create, start, stop and destroy will probably also be called by MC (in about the same way we now call the @Management interface).

[alrubinger]

Thanks for pointing out EJBTHREE-655.

"wolfc" wrote:
What is easily possible is a MC view on an EJB. This should not require any new container and should be applicable to both SLSB and Service/Singleton.

This was actually my last thought before bed last night. :)

"wolfc" wrote:
As for the actual life cycle callbacks, these are @PostConstruct and @PreDestroy.
Although create, start, stop and destroy will probably also be called by MC (in about the same way we now call the @Management interface).

@PostConstruct and @PreDestroy are different; that's per bean instance. I'm looking to get Annotations for "create/start/stop/destroy" at the Container level, much like MC has for POJOs. We already have these within the container itself; I want to also provide a hook for a bean provider to specify methods as callbacks to be invoked along the Container lifecycle, not the instance lifecycle.

S,
ALR

[alrubinger]

And to go full-circle (though not related to the implementation of this topic), we should also be providing a mechanism to inject MC Beans into EJBs. This would enable services to remain mere POJOs, wrappable in EJB.

@Stateless
public class MyBean{
 @InjectMcBeanAnnotation("McBeanName")
 private McBean bean;
}

S,
ALR