[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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 initialization code. This could be done via the MC compiler (MCC or maybe YAMCC). I know that we don't have this now but I like the general idea of pre-compiling/caching what ever stuff makes sense to improve performance. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4244091#4244091 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4244091 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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 approach. jaikiran wrote : | Shouldn't an implicit dependency be turned (by some piece of code) into an explicit dependency? For #1, the other bean is actually depending on the some bean for the static flag, so shouldn't this dependency be created explicitly? Same holds for #2 | Not all dependencies could be made explicit. e.g. let's again take the JNDI example One bean all it cares is if certain JNDI name is present. The other one or a few are potential candidates to provide this JNDI name. But the catch is that providing this name depends on N variables; timestamp, weather, ... So, there is no way to know in a particular timeframe which bean will resolve the first bean -- implicit. jaikiran wrote : | Isn't this expensive (correct me if i am wrong) and is being done for every context being installed. 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? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4244058#4244058 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4244058 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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 fact, all of our services in AS should be explicit. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4244481#4244481 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4244481 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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 depending on JNDI, I think that should always translate into a real explicit dependency, which is filled by a special bean deployment that represents the JNDI binding. These special deployments can be implicitly created by the EJB and JCA deployers, much like how I bind logging handlers to logger categories. I think that the value of having a highly efficient (and simple) dependency resolution algorithm will far, far outweigh its support for edge cases that can be easily implemented in other ways. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4244482#4244482 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4244482 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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, something else tries to pull that out Not to mention it would be too much + duplicated work to check for only those which might be affected by this new install / move. Whereas this is simple, but pretty much bullet proof concept. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4243789#4243789 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4243789 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
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 implicit dependencies | * some bean sets some static flag, the other one inspects that as its dependency | * we put something into JNDI, something else tries to pull that out | Shouldn't an implicit dependency be turned (by some piece of code) into an explicit dependency? For #1, the other bean is actually depending on the some bean for the static flag, so shouldn't this dependency be created explicitly? Same holds for #2 alesj wrote : | Not to mention it would be too much + duplicated work to check for only those which might be affected by this new install / move. | Whereas this is simple, but pretty much bullet proof concept. Looking at what resolveContexts does: 1) Get all possible From and To states 2) Try to resolve all contexts for each of these From state to To state 3) #2 internally involves resolving dependencies of each of these contexts 4) Install any resolved contexts Isn't this expensive (correct me if i am wrong) and is being done for every context being installed. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4243825#4243825 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4243825 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
