jboss-dev-forums

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<ad...@jb...>]

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882849#3882849

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882849

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<ad...@jb...>]

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882850#3882850

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882850

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<sco...@jb...>]

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883093#3883093

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883093

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<dim...@jb...>]

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883101#3883101

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883101

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<ad...@jb...>]

"sco...@jb..." wrote : So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation?
  | 

OK 

anonymous wrote : 
  | 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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883102#3883102

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883102

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<ad...@jb...>]

"ad...@jb..." wrote : 
  | 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

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883104#3883104

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883104

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: SubDeployer interceptors in 4.x/HEAD

[<ad...@jb...>]

"dim...@jb..." wrote : 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.

anonymous wrote : 
  | 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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883109#3883109

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883109