>From Trustin Lee (Netty author): I've just finished a preliminary integration layer for Netty and Microcontainer. I thought about adding various metadata and things like that, but ended up with just providing some singletons because Netty is basically a framework so there's nothing much to provide in deployment time. Here's jboss-beans.xml I wrote: * http://tinyurl.com/7668pk
A user will get a proper ChannelFactory implementation via injection: | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer | bean-deployer_2_0.xsd" | xmlns="urn:jboss:bean-deployer:2.0"> | | <bean name="DiscardServer" | class="net.gleamynode.tmp.discard.DiscardServer"> | <constructor> | <parameter class="org.jboss.netty.channel.ChannelFactory"> | <inject | bean="org.jboss.netty.channel.socket.ServerSocketChannelFactory" /> | </parameter> | </constructor> | </bean> | </deployment> | It seems to work fine so far. The next step is to write three modules: * Business logic handler * Google protobuf based protocol codec * A glue module that combines all together to run the server up (will look up proper handler and codec instances via KernelController - I guess it's a piece of cake, right?) By doing so, I'd like to show that a user can upgrade the protocol codec or business logic in runtime without interruption. That is, dropping an updated JAR into the sandbox directory should affect the application immediately. I think just looking for a bean via KernelController for every connection will not work because a JAR will be undeployed and deployed when a new JAR is dropped and therefore the bean I am looking for might disappear during the redeployment. Should I use some call back in this case, or does MC hide this race condition during upgrade (or redeployment)? BTW, I still didn't figure out how to hide internal beans. How can I exactly do that? I looked into the test cases and PreInstallsAction.java but I guess I'm not following the speed of your thought. An example would be appreciated. ;-) I'm also thinking about distributing a minimal JBossMC binary tarball with my tutorial so that a user can play with MC more easily (i.e. untar and drop the sample JARs etc etc). I think it might help MC adoption because people are really used to just downloading a Tomcat tarball and dropping a WAR and see it working. We already have something similar in jboss-demos, but I think it needs to be a binary form so that users can familiarize with MC quickly. I can do this while I write my tutorial. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200972#4200972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200972 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user