During implementation of the block factories I've got a few issues I would like to discuss.
First, it is not clear to me if block factories belong to applications or to the kernel. Here are my pros and cons Factories are part of applications Pro: factories provide application specific logic to initialize blocks thus they belong to applications Con: factories provide application metadata (specifically, BlockInfo) this means they must be up-and-running before an application is started. Initialization of factories as part of application startup has following problems - factories' lifecycle needs to be managed separately from other application blocks; it is difficult to verify application consistency due to the fact that factories must be started before rest of the application is even assembled. Factories are part of the kernel Pro: factories can be managed in the same way other part of the kernel are, they can depend on other services deployed into the kernel and so on. No additional code is required. Con: there is no way to a factory to have application specific configuration, like ip address of remote server; assemble.xml references entities not declared inside the application. Personally, I tend to deploy factories into the kernel but would like to know your opinion. Second, implementation of objects returned from BlockFactory#createObject gets pretty ugly. To describe the problem better let me introduce usage scenario we can talk about. My test system consists of two JVM (JVM-A and JVM-B). JVM-A runs MX4J MBeanServer and has "mydomain:name=mybean" mbean of type test.MyMBean and JRMP adaptor for remote access. JVM-B run phoenix application which has block "jmx-client" that needs services provided by "mydomain:name=mybean". Both JVM-A and JVM-B have same lifetime, i.e. they both started and stopped simultaneously. Lets also assume that JVM-B has "remote-jmx-server" block that provides service "mx4j.connector.RemoteMBeanServer" and knows how to connect to JVM-A. Problem: write and deploy "remote-mbean" block that provides service "test.MyMBean" to JVM-B. The issue is that "remote-mbean" block needs to implement service interface which is not known at block's compile time as well as a number of avalon's interfaces (Serviceable in particular). My original proposal had new phoenix interface "org.apache.avalon.phoenix.Invokeable" which extends "java.lang.reflect.InvocationHandler". Implementation of this interface informs phoenix that it should call block.invoke(..) when somebody wants to use block's services. Now I also want to introduce yet another interface "org.apache.avalon.phoenix.ProxyProvider" that'll have single method "Object getProxy()" and will serve same purpose as Invokeable but use proxy object provided by the block. Thoughts? PS: I only wonder why do my messages are getting so long? Peter Donald wrote: > On Tue, 20 Aug 2002 23:13, Igor Fedorenko wrote: > >>Peter Donald wrote: >> >>>On Tue, 20 Aug 2002 00:59, Igor Fedorenko wrote: >>> >>>>Not exactly. Soap does not have to be java, so getting "all remote >>>>interfaces" of none-java service would be tricky. Of course, one could >>>>write a factory that is smart enough to map soap urls into java >>>>interfaces, but this sounds like hiding problems instead of solving them. >>> >>>If that is the case you could still use the same interface with a slight >>>modification >>> >>><block name="my-block-remote" >>> impl="resource:/my/soap/descriptor.xml" >>> factory="org.apache.avalon.factorys.SoapFactory"> >>></block> >> >>In fact, I cheat here -- encode service definition into "impl". >> >>So, lets say you've almost ;-) convinced me. I am going to implement >>this as well as invocation interceptors and will post a patch sometime >>later this week. > > > kool! > -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
