Re: Phoenix Block

[Peter Donald <pe...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>