You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2001/11/28 16:08:35 UTC
Phoenix Block
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. 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.
Example:
Main Application
|
|--TimeService Block
|
|--NamingService Block
|
|--PKI Application Block
| |
| |-- Certificate Repository Block
| |-- CertificationAuthority Block
| |-- RegistrationAuthority Block
|
|--Collaboration Application Block
| |
| |-- User Block
| |-- Task Block
| |-- Message Block
| |-- Processor Block
| |-- Workspace Block
| |-- Commumnity Block
| |-- Encounter Block
|
|--Customer Solution Block
|
|-- BusinessProcess-1 Block
|-- BusinessProcess-2 Block
|-- BusinessProcess-3 Block
This raises a few questions:
1. Does anyone know if there is any similar or related development?
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
3. Are there any major problems that are likely to be encountered?
4. Is a nested environment.xml necessary/desirable?
5. What elements/features of a application-block should reside
at the root phoenix level (e.g. extensions directory, logging,
etc.)
Cheers, Steve.
Stephen J. McConnell, OSM sarl
digital products for global business
http://www.osm.net
mailto:mcconnell@osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenix Block
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
Is it that you really need block within block (within block potentially)
functionality or do you really need IoC within Ioc (within Ioc)?
Block (formerly .bar file) is already within server application (.sar
file) and the killing/removing/etc of the .sar one day will
kill/remove/etc all the blocks within it.
If is an intersting proposition though :
interface Block {
......
mountSubBlock(...);
unMountSubBlock(...);
}
- Paul
>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. 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.
>
>Example:
>
> Main Application
> |
> |--TimeService Block
> |
> |--NamingService Block
> |
> |--PKI Application Block
> | |
> | |-- Certificate Repository Block
> | |-- CertificationAuthority Block
> | |-- RegistrationAuthority Block
> |
> |--Collaboration Application Block
> | |
> | |-- User Block
> | |-- Task Block
> | |-- Message Block
> | |-- Processor Block
> | |-- Workspace Block
> | |-- Commumnity Block
> | |-- Encounter Block
> |
> |--Customer Solution Block
> |
> |-- BusinessProcess-1 Block
> |-- BusinessProcess-2 Block
> |-- BusinessProcess-3 Block
>
>This raises a few questions:
>
>1. Does anyone know if there is any similar or related development?
>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
>3. Are there any major problems that are likely to be encountered?
>4. Is a nested environment.xml necessary/desirable?
>5. What elements/features of a application-block should reside
> at the root phoenix level (e.g. extensions directory, logging,
> etc.)
>
>Cheers, Steve.
>
>Stephen J. McConnell, OSM sarl
>digital products for global business
>http://www.osm.net
>mailto:mcconnell@osm.net
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenix Block
Posted by 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>