So a user has a scenario that could
M1 <-Pa-> M4 <-Pd-> |
*
M2 <-Pc-> M5 <-Pd-> M7
*
M3 <-Pb-> M6 <-Pe-> |
Px = protocol x with seperate contract_x.jar for interfaces
Mn = mbean n that depends on one or more protocols
whenever a protocol contract jar for which mbeans 1..m depend
on is deployed, mbeans 1..m need to be redeployed. This could
potentially be addressed by extending the current dependency
notion to optionally support redeployment, not just stopping
of the service.
However, in general when contract_x.jar is redeployed, its
not sufficient to simply redeploy the mbeans using the contract,
since at least one of them also needs to be upgraded to use the
modified contract. It seems as though the behavior needed is
that if the contract_x.jar is redeployed, all mbeans depending
on the contract are undeployed, and are not redeployed until
their deployment jar is updated by actually being changed or
just touched.
So the model seems to require an alternate hot deployment service
that has the notion of levels and compartments. At a given level
services are generally independent, but can be made dependent
by lifecycle contract as can be done now. The level below has
a deployment level dependency on the level above in that a redeployment
of a higher level compartment causes an undeploy of the services
depending on that compartment.
New issues this raises:
- The directory structure will not correspond to the levels in general
because a service an mbean can be using multiple protocols, and thus
depend on multiple compartments in the level above. So there has to
be a new dependency description mechanism to say service S1 depends on
compartment level L1a in terms of redeployment. This is going to have
to be a representation of a directed graph describing the inter-level
and intra-level dependencies.
- Updating a contract_x.jar deploys the dependent services and these
remain updeployed until explicitly redeployed or touched. This can't
result in exceptions, but could result in services not being redeployed
if the admin forgets.
- What happens to the upstream services? So in the above diagram,
contract_Pd.jar
is redeployed which affects M4, M5, M7 by type, and M1, M2, and M6 due
to service
availability of M7. M4, M5, and M7 must be redeployed, M1, M2, and M6
simply have
to wait for M4, M5, and M7 respectively. What support is jboss providing
vs
what do you have to code to make this work is the question.
In general this issue raises an issue that has come up a few times due
to
the fact that dependency does not have anything to do with redeployment,
even
though dependency may require redeployment if type system involved in
the
dependency changes. Our service dependency needs to expand to support
the
possibility of dependency to the redeployment level.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
