Yeah, I don't buy this "implicit dependencies" business. The beauty of the MC
deployer architecture is that when you deploy stuff, you can make dependencies
which are implicit (as far as the user sees) translate to explicit dependencies
before the container even sees the deployment.
As for "de
Hmm, would it not be more efficient to build a dependency tree/graph in a first
pass, and then process explicit deps in order. Then the remaining "implicit"
deps can be processed brute-force. This of course assumes that the majority of
deps are explicit, which is something we want in the AS. In
"jaikiran" wrote :
| Isn't that the job of the deployers (ex: BeanMetadataDeployer) to install
(which internally will move it to various states) the specific context(s)?
|
Deployers are just one way of installing a component into MC.
You can do it in many different ways - take any direct API
anonymous wrote :
| Re-read the JNDI example. ;-)
| Or how else are you gonna make sure you don't miss a potential dependency
resolving bean,
| if you don't check them all?
|
One idea would be to process the dependencies statically via an
installation/configuration step that generates
"alesj" wrote :
| Or how else are you gonna know what and when something can be moved?
|
Isn't that the job of the deployers (ex: BeanMetadataDeployer) to install
(which internally will move it to various states) the specific context(s)?
"alesj" wrote :
| e.g. you might have some implici
Whenever something gets installed we try to move whatever can be moved.
Or how else are you gonna know what and when something can be moved?
e.g. you might have some implicit dependencies
* some bean sets some static flag, the other one inspects that as its dependency
* we put something into JNDI,
