SubDeployer interceptors in 4.x/HEAD

[dimitris]

So the ability to dynamically attach jmx interceptors to any XBeans in general, and a set of SubDeployers in particular, exists both in 4.x.(3) and HEAD.

The EJB, EJB3, and Web Deployes can be currently intercepted, (i.e. they've been XMBea-nized, with the DynamicInterceptor attached) but we may do the same for any subdeployer.

Note, this is standard xmbean stuff, it's not related to jboss aop.

This feature is already used in HEAD for the new WebService subdeployers, that can attach dynamically, do their own thing and fail a deployment if something goes wrong with the webservices part of the deployment.

There is also an older prototyped LoginConfigInterceptor that detects the presence of a META-IN/login-config.xml and creates/destroys a security domain upon deployment, undeployment (although this needs work when dealing with multiple/nested login-config.xml descriptors>)

Except for WebServices, this feature should be useful to the JBoss Portal deployer. We could also try to process custom log4j.xml descriptors?

You can read about it here:

http://wiki.jboss.org/wiki/Wiki.jsp?page=SubDeployerInterceptorSupport
http://wiki.jboss.org/wiki/Wiki.jsp?page=InterceptorServiceMBeanSupport
http://wiki.jboss.org/wiki/Wiki.jsp?page=DynamicInterceptor

A related forum posting is this:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57296&postdays=0&postorder=asc&start=0

[adrian.brock]

My objections to this still stand to this.
This is not something I want to support going forward in this format.

1) How does it cope with class redeployment of the interceptor, who holds the state?

2) The lifecycle is wrong since the interceptor waits for the service,
thus potentially missing some deployments:

<depends-list optional-attribute-name="Interceptables">
 <depends-list-element>jboss.ejb:service=EJBDeployer</depends-list-element>
 <depends-list-element>jboss.ejb3:service=EJB3Deployer</depends-list-element>
 <depends-list-element>jboss.web:service=WebServer</depends-list-element>
</depends-list>

3) When it is late bound how does it intercept previous deployments?

4) When the interceptor is unbound does it "unintercept"

5) How does this play with the already overly compliated (and broken)
deployer/subdeployment lifecycle.

[adrian.brock]

Rhetorical question.

Also, can we stop dumping everything in org.jboss.system/deployment?

System is for the core kernel, not for every possible helper class that uses
system and deployment. The helper classes should be written to the system api
not digging around in implementation details.

I know we don't have a project that for helpers except varia which is just another
form of dumping ground.

This whole dependency on implementation thing is getting way out of hand.
It is going to be impossible to change a single line of code soon without breaking
backwards compatibility.

[starksm64]

So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation?

As for not supporting this in the future, what is the main problem, not being able to adapt this behavior to the jb5 kernel? I understand and agree with the numerous problematic issues you raised in your objections.

We need to add interceptors on the deployers as a first class notion, not through xmbean tricks.

[dimitris]

This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s).

It can be somewhat improved by not having a dependency and start dealing with registration notifications, but that's just as far you can get.

The "interceptors" really need to register with the MainDeployer, because this is the only way to be informed of past deployments, and get the lifecycle right. This is in Adrian's deployer design, anyway.

We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support.

[adrian.brock]

So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation?

OK

As for not supporting this in the future, what is the main problem, not being able to adapt this behavior to the jb5 kernel?

1) It would require yet another compatibility layer to invoke user written XMBean deployment interceptors from the aspectized deployers.

2) The purpose of the aspectized deployers is to work on the metadata model of the
deployment.
deployment aspects -> metadata -> kernel -> objects
This XMBean interception approach is just a form of scripting
deployment -> interceptor -> anything at all
with the kernel having no understanding of how the "anything at all" fits into
the system for dependencies/classloading/lifecycle/mangement/etc.
let alone trying to describe the possible deployment configuration to tools.

[adrian.brock]

deployment aspects -> metadata -> kernel -> objects
...
let alone trying to describe the possible deployment configuration to tools.

In the more complicated tool workflow:

raw deployment -> deployment aspects -> metadata ->
user review/change -> metadata -> versioned config -> kernel -> objects

[adrian.brock]

This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s).

Yes, it is a mechanism that helps in the decoupling of the aspects of deployment
e.g. creating webservice endpoints
but my main problem with it that it does nothing to expose what is happening
to the deployment.
At least in the "monolithic" SubDeployer architecture there is some attempt
to collect the deployment description in DeploymentInfo.

We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support.

Scott already raised the issue of each project describing what is its "public api"
supported across versions, as oppossed to implementation details or internal
integration routines that happen to be public classes.