Hi, Very interesting subject and something I really really want to hack on ;)
BTW it fits really well with one of the requirements stated in the Myth of COde centricity article http://www.javaworld.com/jw-08-2001/jw-0824-myth.html On Thu, 29 Nov 2001 02:08, Stephen McConnell wrote: > I've been thinking about a Phoenix Block for some time. That is > to say a Block that encapsulates the phoenix kernel and runs > within a Phoenix application. The way I originally envisioned it was that a Block would contain an Application object. If you notice that I separated out an ApplicationContext interface that is relatively easy to implement. So a Block could provide an implementation of ApplicationContext and then launch the application that way. So you woulc have something like class AbstractContainerBlock implements ApplicationContext {} class MyBlock extends AbstractContainerBlock > This would enable the creation > of block hierarchies. For example, imagine have a block which > provides the establishment of a context for a set of subsidiary > blocks - if I stop/suspended the parent block, all subsidiary > blocks would be stopped as well. Removing a parent block would > imply removal of child blocks. This approach enables a separation > of functional units - dependencies at the level of an application > can be encapsulated and separated from external operational > dependencies and public services. yep. > 1. Does anyone know if there is any similar or related development? HPs services kernel does it to a certain degree. It is a slightly different model though and requires a bit more knowledge from users. > 2. What is good starting point in-terms of the > existing Phoenix platform classes/interfaces. > - initial throughts are that thgis would look something like > a varient of the PhoenixServlet/SingleAppDeployer That would be the "low cost" approach. You could probably get it up and running fast but it would cause you hassles in the long run I fear. Most of the work I have been doing has been aimed at enabling this sort of thing. There is a few things I have yet to figure out a good way of doing .. Heres the way I see it should work. First we create a set of ClassLoaders that are appropriate for the Application. I will send details in another mail. This essentially is about hte hierarchial ClassLoaders that I have talked about recently. So lets take the "Collaboration Application" Block in your example. * The Block would retrieve the "collab" ClassLoader from BlockContext and this would be what it uses to create all it's sub-blocks. * The Block would load the assembly configuration from classloader - something like final InputStream input = classLoader.getResourceAsStream( "SAR-INF/collab-assembly.xml" ); Configuration config = buildConfig( input ); * load config data in similar fashion * assemble the SarMetaData via something like final SarMetaData metaData = assembler.assembleSar( "collab", config, getBlockContext().getHomeDirectory(), collabClassLoader ); * verify the application via verifier.verifySar( metaData, collabClassLoader ); * make Block implement ApplicationContext. It returns cached values of metaData, ClassLoader, config data and creates subLoggers of current block as appropriate. * create and setup an instance of Application via something like DefaultApplication app = new DefaultApplication(); setupLogger( app ); app.setApplicationContext( this ); app.start() and voila! Should be good to go. > 3. Are there any major problems that are likely to be encountered? - You need to rearange jar that contains "container" so that required parts are in shared directory. - Potentially keep up with interface changes in APplication or whatever as it evolves (and it still needs to) - When I/we fully implement JMX management then you may need a masiive reorganization (or may not), hard to tell at this stage though. > 4. Is a nested environment.xml necessary/desirable? I am of two minds about this. I suspect not. See above re: Classpath/ClassLoader issues. Logging/policy could also be done for whole application at once aswell. > 5. What elements/features of a application-block should reside > at the root phoenix level (e.g. extensions directory, logging, > etc.) Extensions would be at the top level but all the rest could done either in AbstractContainerBlock or environment.xml. ------------------------- Anyways I would really love to help you implement this but I also want to get Phoenix to beta real soon now. Currently the thing holding it up is the lack of proper JMX integration - unfortunately I don't (and won't) use that part in my own apps so I am finding it difficult to get motivated enough to do it ;) Anyways if you still haven't implemented it by the time I finish that I will have a go at doing that. -- Cheers, Pete *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
