You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/05/10 16:18:44 UTC
Phoenixs Deprecated features
Hi,
I am slowly going through and preparing Phoenix for another release. This
involves cleaning up bits and pieces and making sure everything that is
supposed to work, actually works.
Some of the following things are deprecated and have been for a while. I would
like to know if anyone is using any of these features and if so tell me so
they can be preserved.
NOTE: Please send replies to the avalon-phoenix-dev mailing list so that this
can be coordinated in one place.
Heres the list of changes that I want to implement. If there is no negative
responses by next weekend I will go ahead and do it.
----------------------------------------------------------------------------------------
Feature: Threads pools accessible from BlockContext
Deprecated since: 2001/09/20
ie The check if the following methods are used anywhere in your code.
BlockContext.getThreadPool(String)
BlockContext.getDefaultThreadPool()
----------------------------------------------------------------------------------------
Feature: BaseLogger accessible from BlockContext
Deprecated since: Sometime before 2001/04/27
ie The check if the following methods are used anywhere in your code.
BlockContext.getBaseLogger()
----------------------------------------------------------------------------------------
Feature: Using elements named "block-listener" in assembly.xml
Deprecated since: 2002/01/26
ie the correct element name is <listener/> now so as not to confuse
differences between Block and Applicaiton Listeners.
----------------------------------------------------------------------------------------
Feature: Using config elements named"management" to expose services as MBeans
Was only Non-deprecated between 2002/01/12 and 2002/01/25
ie the correct element name is <management-access-points/>
----------------------------------------------------------------------------------------
Feature: Using Service class
Deprecated since: 2001/09/25
Deprecated with no replacement.
----------------------------------------------------------------------------------------
Feature: Old .sar packaging format
Deprecated since: 2001/10/22
The .sar format previously allowed all blocks to be stored in
blocks/*.bar and libraries to be stored in lib/*.zip, lib/*.jar. This has been
changed so that all jars/libraries are stored in SAR-INF/lib/*.jar and also
allows class files in SAR-INF/classes. The configuration files have also
moved into SAR-INF/*.xml
----------------------------------------------------------------------------------------
Feature: Directly Using LogKit Logger
Deprecated since: 2001/10/31
We have been using a Logging facade (in o.a.a.framework.logger.*) for a while
now but have had to support the old form of using the LogKit logger directly.
Dropping support for non-facade would allow us to remove yet another
dependenancy from deployed applications (and allow us to use JDK1.4 Logging
where supported).
----------------------------------------------------------------------------------------
Feature: Use old config file name server.xml
Deprecated since: 2001/11/10
SAR-INF/server.xml was renamed to SAR-INF/environment.xml because phoenix and
this configuration was not specific to servers but to the environment in
which the applicaiton executes.
----------------------------------------------------------------------------------------
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Royal <pr...@apache.org>.
On Friday 10 May 2002 10:18 am, Peter Donald wrote:
> ---------------------------------------------------------------------------
>------------- Feature: Directly Using LogKit Logger
> Deprecated since: 2001/10/31
>
> We have been using a Logging facade (in o.a.a.framework.logger.*) for a
> while now but have had to support the old form of using the LogKit logger
> directly. Dropping support for non-facade would allow us to remove yet
> another dependenancy from deployed applications (and allow us to use JDK1.4
> Logging where supported).
I'm still using this one as I have a block that creates an ECM. I plan to
move towards fortress but don't have a firm timetable yet.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>Heres the list of changes that I want to implement. If there is no negative
>responses by next weekend I will go ahead and do it.
>
>----------------------------------------------------------------------------------------
>Feature: Threads pools accessible from BlockContext
>Deprecated since: 2001/09/20
>
> ie The check if the following methods are used anywhere in your code.
> BlockContext.getThreadPool(String)
> BlockContext.getDefaultThreadPool()
>
I am using, but will switch to direct use of ThreadManager.
>Feature: Using elements named "block-listener" in assembly.xml
>Deprecated since: 2002/01/26
>
>ie the correct element name is <listener/> now so as not to confuse
>differences between Block and Applicaiton Listeners.
>
>
I'll get all the avalon-* blocks in order on this.
no objections..
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Donald <pe...@apache.org>.
Hi
This will have been completed by the end of today.
On Sat, 11 May 2002 00:18, Peter Donald wrote:
> Hi,
>
> I am slowly going through and preparing Phoenix for another release. This
> involves cleaning up bits and pieces and making sure everything that is
> supposed to work, actually works.
>
> Some of the following things are deprecated and have been for a while. I
> would like to know if anyone is using any of these features and if so tell
> me so they can be preserved.
>
> NOTE: Please send replies to the avalon-phoenix-dev mailing list so that
> this can be coordinated in one place.
>
> Heres the list of changes that I want to implement. If there is no negative
> responses by next weekend I will go ahead and do it.
>
> ---------------------------------------------------------------------------
>------------- Feature: Threads pools accessible from BlockContext
> Deprecated since: 2001/09/20
>
> ie The check if the following methods are used anywhere in your code.
> BlockContext.getThreadPool(String)
> BlockContext.getDefaultThreadPool()
> ---------------------------------------------------------------------------
>------------- Feature: BaseLogger accessible from BlockContext
> Deprecated since: Sometime before 2001/04/27
>
> ie The check if the following methods are used anywhere in your code.
> BlockContext.getBaseLogger()
> ---------------------------------------------------------------------------
>------------- Feature: Using elements named "block-listener" in assembly.xml
> Deprecated since: 2002/01/26
>
> ie the correct element name is <listener/> now so as not to confuse
> differences between Block and Applicaiton Listeners.
> ---------------------------------------------------------------------------
>------------- Feature: Using config elements named"management" to expose
> services as MBeans Was only Non-deprecated between 2002/01/12 and
> 2002/01/25
>
> ie the correct element name is <management-access-points/>
> ---------------------------------------------------------------------------
>------------- Feature: Using Service class
> Deprecated since: 2001/09/25
>
> Deprecated with no replacement.
> ---------------------------------------------------------------------------
>------------- Feature: Old .sar packaging format
> Deprecated since: 2001/10/22
>
> The .sar format previously allowed all blocks to be stored in
> blocks/*.bar and libraries to be stored in lib/*.zip, lib/*.jar. This has
> been changed so that all jars/libraries are stored in SAR-INF/lib/*.jar and
> also allows class files in SAR-INF/classes. The configuration files have
> also moved into SAR-INF/*.xml
> ---------------------------------------------------------------------------
>------------- Feature: Directly Using LogKit Logger
> Deprecated since: 2001/10/31
>
> We have been using a Logging facade (in o.a.a.framework.logger.*) for a
> while now but have had to support the old form of using the LogKit logger
> directly. Dropping support for non-facade would allow us to remove yet
> another dependenancy from deployed applications (and allow us to use JDK1.4
> Logging where supported).
> ---------------------------------------------------------------------------
>------------- Feature: Use old config file name server.xml
> Deprecated since: 2001/11/10
>
> SAR-INF/server.xml was renamed to SAR-INF/environment.xml because phoenix
> and this configuration was not specific to servers but to the environment
> in which the applicaiton executes.
> ---------------------------------------------------------------------------
>-------------
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Sat, 11 May 2002 12:07, Stephen McConnell wrote:
>
>>Pete:
>>
>>No problem with any of the proposed changes.
>>
>
>kool.
>
>
>>I would like to see addition of support for CascadingConfigurations
>>together with the addition of extensions to the .xinfo file to contain a
>>default confituation declararation (which would bring Phoenix and Merlin
>>almost totally in sync). Any thoughts about how this can be achieved?
>>
>
>A few. Currently I am working on trying to get decent interoperability between
>Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has
>slightly different needs there is also a bunch of common ground. Currently
>the main things I am interested is getting together a single representation
>of component meta data.
>
>The types of component meta data I am thinking of is mainly;
>
>* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is
>singlethreaded etc
>
Just a note that I think that we will sooner or later have to deal with
the pooled concept at the framework - by the addition of a specific
interface for a Pool, or, elimination of pooling notions at the level of
ServiceManager and ComponentManager.
>
>* context:
> - Context Class
> - Entrys in Context (both name of entry and type of entry)
>
I'm assuming you mean something along the lines of
org.apache.excalibur.context.ContextUtility (which I'm using within
Merlin). It handes the above but the javadoc really needs some work.
>
>* service:
> - services required by component
>* configuration/parameters:
> - schema+validaiton of Configuration/Parameters
>
>In each different container the info is represented differently. However what
>I was thinking of was developing a set of standard javadoc tags and
>processing the sourcefile using the XDoclet tool available at;
>
>http://sourceforge.net/projects/xdoclet
>
>This tool would generate the manifest files, blockinfos, possibly default
>configurations and so forth in context of Phoenix/Merlin.
>
This is probably the asiest first step.
>
>With a different template you could use XDoclet to generate the descriptor
>files for Fortress/ECM/Myrmidon.
>
>
>> Inital ideas are either (a) implict addition of default configuration
>>handling within Phoenix, or (b) the ability to declare an
>>alternative/pluggable configuration resolver.
>>
>
>Technically is possible now. I could even add in plugin points to the deployer
>if you really want this right away (And you could just create a custom
>MerlinDeployer that uses CascadingConfiguration).
>
>I was going to try address it in a global manner first but if you want me to
>make it possible for you to overide default behaviour with
>CascadingConfigurerr then it should be relatively easy. Just say the word.
>
Before answering the above, I'll go into a more detail concerning Merlin
configuration semantics. First of all - the import differences between
Merlin and Phoenix is that Merlin's support for assembly is much more
limited than Phoenix - but the other side of the coin is that it handles
component assembly and execution without the overhead of assembly.xml,
environment.xml, etc. Merlin achieves this through extensive
application of cascading configuration information. For a top-level
target component Merlin is the container. The target configuration is
created based on the following:
(primary) (parent)
<configuration-file> <target-xinfo.configuration>
| |
---------------------------
|
<target-configuration>
Based on the dependencies declared in the .xinfo file, the container
creates and populates a service manager (or component manager) using the
following cascading configuration schema:
(primary) (parent)
<container.dependency.configuration> <dependent-xinfo.configuration>
| |
-----------------------------------
|
(primary) (parent)
<target-configuration.role> <dependant-configuration>
| |
-----------------------------
|
<dependent-configuration>
The above graph assumes two extensions to the Phoenix .xinfo schema.
Firstly, there is the usage of a <configuration> declared as a child of
the <block> element (typically used to hold release related
configuration info (as distinct from deployment configuration info).
Secondly, Merlin looks for a <configuration> element declared within a
dependency declaration and uses this in the construction of a
configuration chain for the dependent service. The overriding principal
is that this collection of information should enable the complete
establishment of a component and that the level of site configuration
should be very small if not totally eliminated.
Example .xinfo file:
The dramtically simplifies site confugration and lets me seperate relase
configuration from deployment configuration (i.e. I put release
configuration in the .xinfo and deployment configuration in a seperate
modifyable configuration file). The second area that I've been playing
around with is the inclusion of a configuration element within a
dependency declaration. The purpose of this is to declare the default
configuration profile for role.
Example:
<blockinfo>
<block name="my-service">
<version>1.0</version>
</block>
<services>
<service name="net.osm.HelloService" version="1.0" />
</services>
<dependencies>
<dependency>
<role>directory</role>
<service name="net.osm.directory.DirectoryProvider" version="2.4"/>
<configuration>
<!--
This contains a configration elements that are used
to ensure that the dependent service is appropriately
configurared. For example, the HelloService may need
an orb that is preconfigurated with a POA and
NamingService - as such, the configuration elements
included here can be considered as constraints applied
by the HelloService that must be fulfilled by its
container.
-->
</configuration>
</dependency>
<dependencies>
<configuration>
<!--
This configuration element contains the default configuration
for the component.
-->
</configuration>
For completeness, there are two other .xinfo additions that should be
noted. Firstly, there is the introduction of the name attribute on the
block element. This is used to establish the name to assign to a
logging channel for the root component. Secondly, Merlin supports a
<context> declarations within a .xinfo which is handled by the
ContextUtility class.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Donald <pe...@apache.org>.
On Sun, 12 May 2002 12:11, Stephen McConnell wrote:
> >I also plan to use the converter architecture (in excalibur now,
> > previously of myrmidon) to help with populating the context. Basically
> > converter architecture tries to convert from one type to another type.
>
> Can you give me some liks/references etc. to <resource-ref/>
I am not sure there is any central place where this is documented (except for
maybe in the EJB/Servlet/other specs). Theres some data on it at
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
But basically it comes down to the following. Each application/bean/whatever
can declare that it needs other sresources via something like
<resources-ref>
<description>...</description>
<res-ref-name>myKey</res-ref-name>
<res-ref-type>java.lang.Integer</res-ref-type>
<res-auth>Container</res-auth>
</resources-ref>
Translated into avalon terms this would say that the is an entry in the
context under key "myKey" that is of type "java.lang.Integer". Avalon has no
notion of authenticating (thus no need for res-auth) because we have no need.
> and the
> converter stuff
Just look in
jakarta-avalon-excalibur/converter
Basically it contains a bunch of converters that convert strings into types
(like Integers, Longs etc). And there is a master converter that you use like
final Converter c = ...get master converter...;
final Integer i = (Integer)c.convert( Integer.class, "53", null );
So basically you convert to a destination type (Integer.class) from a source
object ("53") in a specific context (null).
> >>Before answering the above, I'll go into a more detail concerning Merlin
> >>configuration semantics.
> >
> >...snip...
>
> There you go again ... snipping the best bits of my emails!
>
> :-)
:)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Sun, 12 May 2002 09:51, Stephen McConnell wrote:
>
>>>* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe,
>>>is singlethreaded etc
>>>
>>Just a note that I think that we will sooner or later have to deal with
>>the pooled concept at the framework - by the addition of a specific
>>interface for a Pool,
>>
>
>Thats how it used to be back a while ago. We used to have Poolable and Pool
>interface inside the framework proper. Thankfully that got moved out.
>
>
>>or, elimination of pooling notions at the level of
>>ServiceManager and ComponentManager.
>>
>
>+1
>
Thats my preference as well.
(But we know that this is am emotive topic!).
>
>>>* context:
>>> - Context Class
>>> - Entrys in Context (both name of entry and type of entry)
>>>
>>I'm assuming you mean something along the lines of
>>excalibur.context.ContextUtility (which I'm using within Merlin). It
>>handles the above but the javadoc really needs some work.
>>
>
>Very similar. However it needs to be more like J2EE <resource-ref/> in that we
>can map arbitrary types into context. In particular I would like to be able
>to map objects of type MBeanServer into context.
>
>I also plan to use the converter architecture (in excalibur now, previously of
>myrmidon) to help with populating the context. Basically converter
>architecture tries to convert from one type to another type.
>
Can you give me some liks/references etc. to <resource-ref/> and the
converter stuff
>
>
>>>I was going to try address it in a global manner first but if you want me
>>>to make it possible for you to overide default behaviour with
>>>CascadingConfigurerr then it should be relatively easy. Just say the word.
>>>
>>Before answering the above, I'll go into a more detail concerning Merlin
>>configuration semantics.
>>
>...snip...
>
There you go again ... snipping the best bits of my emails!
:-)
>
>
>sounds interesting - I will have a further look. I am not sure thats the right
>way to go with all phoenix but it should be possible to enable by just
>writing a new Deployer. Wait till next weekend (after I put through all
>changes I proposed) and hopefully it will be much easier to enable this sort
>of thing.
>
No problem.
>Currently it is a PITA because we are supporting a bunch of
>deprecated deployment formats (and thus need similar code in multiple
>places). After this is all cleaned up it should be much easier to do.
>
>
>>For completeness, there are two other .xinfo additions that should be
>>noted. Firstly, there is the introduction of the name attribute on the
>>block element.
>>
>
>+1
>
>
>>Secondly, Merlin supports a
>><context> declarations within a .xinfo which is handled by the
>>ContextUtility class.
>>
>
>+1 to idea but I want to play with concept a bit more because I need other
>things to be placed in context that wont be supported by current ContextUtil.
>
>
Agreed.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Donald <pe...@apache.org>.
On Sun, 12 May 2002 09:51, Stephen McConnell wrote:
> >* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe,
> > is singlethreaded etc
>
> Just a note that I think that we will sooner or later have to deal with
> the pooled concept at the framework - by the addition of a specific
> interface for a Pool,
Thats how it used to be back a while ago. We used to have Poolable and Pool
interface inside the framework proper. Thankfully that got moved out.
> or, elimination of pooling notions at the level of
> ServiceManager and ComponentManager.
+1
> >* context:
> > - Context Class
> > - Entrys in Context (both name of entry and type of entry)
>
> I'm assuming you mean something along the lines of
> excalibur.context.ContextUtility (which I'm using within Merlin). It
> handles the above but the javadoc really needs some work.
Very similar. However it needs to be more like J2EE <resource-ref/> in that we
can map arbitrary types into context. In particular I would like to be able
to map objects of type MBeanServer into context.
I also plan to use the converter architecture (in excalibur now, previously of
myrmidon) to help with populating the context. Basically converter
architecture tries to convert from one type to another type.
> >I was going to try address it in a global manner first but if you want me
> > to make it possible for you to overide default behaviour with
> >CascadingConfigurerr then it should be relatively easy. Just say the word.
>
> Before answering the above, I'll go into a more detail concerning Merlin
> configuration semantics.
...snip...
sounds interesting - I will have a further look. I am not sure thats the right
way to go with all phoenix but it should be possible to enable by just
writing a new Deployer. Wait till next weekend (after I put through all
changes I proposed) and hopefully it will be much easier to enable this sort
of thing. Currently it is a PITA because we are supporting a bunch of
deprecated deployment formats (and thus need similar code in multiple
places). After this is all cleaned up it should be much easier to do.
> For completeness, there are two other .xinfo additions that should be
> noted. Firstly, there is the introduction of the name attribute on the
> block element.
+1
> Secondly, Merlin supports a
> <context> declarations within a .xinfo which is handled by the
> ContextUtility class.
+1 to idea but I want to play with concept a bit more because I need other
things to be placed in context that wont be supported by current ContextUtil.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 20:36, Leo Simons wrote:
> Maybe a combination of the two is a good idea (where you lose the
> metadata-related methods). I was thinking about writing some docs about
> "lifestyle" anyway, as most of us grasp the concept but it is not
> defined as such in the docs.
excellent!
> > With a different template you could use XDoclet to generate the
> > descriptor files for Fortress/ECM/Myrmidon.
>
> If this is possible, it seems more logical that instead the descriptor
> files should be more similar...just thoughts.
For the newer containers this is definetly a good idea but for the older ones
we still have to support exisitng config files.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Leo Simons <le...@apache.org>.
> > I would like to see addition of support for CascadingConfigurations
> > together with the addition of extensions to the .xinfo file to contain a
> > default confituation declararation (which would bring Phoenix and Merlin
> > almost totally in sync). Any thoughts about how this can be achieved?
>
> A few. Currently I am working on trying to get decent interoperability between
> Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has
> slightly different needs there is also a bunch of common ground. Currently
> the main things I am interested is getting together a single representation
> of component meta data.
Funny. I was thinking about the same thing last weekend =)
> The types of component meta data I am thinking of is mainly;
>
> * lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is
> singlethreaded etc
> * context:
> - Context Class
> - Entrys in Context (both name of entry and type of entry)
> * service:
> - services required by component
> * configuration/parameters:
> - schema+validaiton of Configuration/Parameters
>
> In each different container the info is represented differently. However what
> I was thinking of was developing a set of standard javadoc tags and
> processing the sourcefile using the XDoclet tool available at;
>
> http://sourceforge.net/projects/xdoclet
>
> This tool would generate the manifest files, blockinfos, possibly default
> configurations and so forth in context of Phoenix/Merlin.
This is a really neat solution. I was thinking about formalising
lifestyle interfaces, and giving them methods that throw
"OperationNotSupportedExceptions" etc.
Maybe a combination of the two is a good idea (where you lose the
metadata-related methods). I was thinking about writing some docs about
"lifestyle" anyway, as most of us grasp the concept but it is not
defined as such in the docs.
Thinking even further....we could also do with @contract for our
interfaces in general...I can see quite a few uses...
> With a different template you could use XDoclet to generate the descriptor
> files for Fortress/ECM/Myrmidon.
If this is possible, it seems more logical that instead the descriptor
files should be more similar...just thoughts.
> > Inital ideas are either (a) implict addition of default configuration
> > handling within Phoenix, or (b) the ability to declare an
> > alternative/pluggable configuration resolver.
>
> Technically is possible now. I could even add in plugin points to the deployer
> if you really want this right away (And you could just create a custom
> MerlinDeployer that uses CascadingConfiguration).
>
> I was going to try address it in a global manner first but if you want me to
> make it possible for you to overide default behaviour with
> CascadingConfigurerr then it should be relatively easy. Just say the word.
well, there you go. Phoenix getting there, Merlin almost there, I'm
guessing Myrmidon as well as it is also your work...seems like I have
less to think about again.
BTW, crossposting to avalon-dev as this concerns excalibur & stuff as
well.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Stephen McConnell <mc...@osm.net>.
Reposting my message with correction to my reply.
Peter Donald wrote:
>On Sat, 11 May 2002 12:07, Stephen McConnell wrote:
>
>>Pete:
>>
>>No problem with any of the proposed changes.
>>
>
>kool.
>
>
>>I would like to see addition of support for CascadingConfigurations
>>together with the addition of extensions to the .xinfo file to contain a
>>default confituation declararation (which would bring Phoenix and Merlin
>>almost totally in sync). Any thoughts about how this can be achieved?
>>
>
>A few. Currently I am working on trying to get decent interoperability between
>Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has
>slightly different needs there is also a bunch of common ground. Currently
>the main things I am interested is getting together a single representation
>of component meta data.
>
>The types of component meta data I am thinking of is mainly;
>
>* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is
>singlethreaded etc
>
Just a note that I think that we will sooner or later have to deal with
the pooled concept at the framework - by the addition of a specific
interface for a Pool, or, elimination of pooling notions at the level of
ServiceManager and ComponentManager.
>
>* context:
> - Context Class
> - Entrys in Context (both name of entry and type of entry)
>
I'm assuming you mean something along the lines of
excalibur.context.ContextUtility (which I'm using within Merlin). It
handles the above but the javadoc really needs some work.
>
>* service:
> - services required by component
>* configuration/parameters:
> - schema+validaiton of Configuration/Parameters
>
>In each different container the info is represented differently. However what
>I was thinking of was developing a set of standard javadoc tags and
>processing the sourcefile using the XDoclet tool available at;
>
>http://sourceforge.net/projects/xdoclet
>
>This tool would generate the manifest files, blockinfos, possibly default
>configurations and so forth in context of Phoenix/Merlin.
>
This is probably the easiest first step.
>
>
>With a different template you could use XDoclet to generate the descriptor
>files for Fortress/ECM/Myrmidon.
>
>
>> Inital ideas are either (a) implict addition of default configuration
>>handling within Phoenix, or (b) the ability to declare an
>>alternative/pluggable configuration resolver.
>>
>
>Technically is possible now. I could even add in plugin points to the deployer
>if you really want this right away (And you could just create a custom
>MerlinDeployer that uses CascadingConfiguration).
>
>I was going to try address it in a global manner first but if you want me to
>make it possible for you to overide default behaviour with
>CascadingConfigurerr then it should be relatively easy. Just say the word.
>
>
Before answering the above, I'll go into a more detail concerning Merlin
configuration semantics. First of all - the import differences between
Merlin and Phoenix is that Merlin's support for assembly is much more
limited than Phoenix - but the other side of the coin is that it handles
component assembly and execution without the overhead of assembly.xml,
environment.xml, etc. Merlin achieves this through extensive
application of cascading configuration information. For a top-level
target component Merlin is the container. The target configuration is
created based on the following:
(primary) (parent)
<configuration-file> <target-xinfo.configuration>
| |
---------------------------
|
<target-configuration>
Based on the dependencies declared in the .xinfo file, the container
creates and populates a service manager (or component manager) using the
following cascading configuration schema:
(primary) (parent)
<container.dependency.configuration> <dependent-xinfo.configuration>
| |
-----------------------------------
|
(primary) (parent)
<target-configuration.role> <dependent-configuration>
| |
-----------------------------
|
<dependent-configuration>
The above graph assumes two extensions to the Phoenix .xinfo schema.
Firstly, there is the usage of a <configuration> declared as a child of
the <block> element (typically used to hold release related
configuration info (as distinct from deployment configuration info).
Secondly, Merlin looks for a <configuration> element declared within a
dependency declaration and uses this in the construction of a
configuration chain for the dependent service. The overriding principal
is that this collection of information should enable the complete
establishment of a component and that the level of site configuration
should be very small if not totally eliminated.
Example .xinfo file:
<blockinfo>
<block name="my-service">
<version>1.0</version>
</block>
<services>
<service name="net.osm.HelloService" version="1.0" />
</services>
<dependencies>
<dependency>
<role>directory</role>
<service name="net.osm.directory.DirectoryProvider" version="2.4"/>
<configuration>
<!--
This contains a configration elements that are used
to ensure that the dependent service is appropriately
configurared. For example, the HelloService may need
an orb that is preconfigurated with a POA and
NamingService - as such, the configuration elements
included here can be considered as constraints applied
by the HelloService that must be fulfilled by its
container.
-->
</configuration>
</dependency>
<dependencies>
<configuration> <!--
This configuration element contains the default configuration
for the component.
-->
</configuration>
For completeness, there are two other .xinfo additions that should be
noted. Firstly, there is the introduction of the name attribute on the
block element. This is used to establish the name to assign to a
logging channel for the root component. Secondly, Merlin supports a
<context> declarations within a .xinfo which is handled by the
ContextUtility class.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Leo Simons <le...@apache.org>.
> > I would like to see addition of support for CascadingConfigurations
> > together with the addition of extensions to the .xinfo file to contain a
> > default confituation declararation (which would bring Phoenix and Merlin
> > almost totally in sync). Any thoughts about how this can be achieved?
>
> A few. Currently I am working on trying to get decent interoperability between
> Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has
> slightly different needs there is also a bunch of common ground. Currently
> the main things I am interested is getting together a single representation
> of component meta data.
Funny. I was thinking about the same thing last weekend =)
> The types of component meta data I am thinking of is mainly;
>
> * lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is
> singlethreaded etc
> * context:
> - Context Class
> - Entrys in Context (both name of entry and type of entry)
> * service:
> - services required by component
> * configuration/parameters:
> - schema+validaiton of Configuration/Parameters
>
> In each different container the info is represented differently. However what
> I was thinking of was developing a set of standard javadoc tags and
> processing the sourcefile using the XDoclet tool available at;
>
> http://sourceforge.net/projects/xdoclet
>
> This tool would generate the manifest files, blockinfos, possibly default
> configurations and so forth in context of Phoenix/Merlin.
This is a really neat solution. I was thinking about formalising
lifestyle interfaces, and giving them methods that throw
"OperationNotSupportedExceptions" etc.
Maybe a combination of the two is a good idea (where you lose the
metadata-related methods). I was thinking about writing some docs about
"lifestyle" anyway, as most of us grasp the concept but it is not
defined as such in the docs.
Thinking even further....we could also do with @contract for our
interfaces in general...I can see quite a few uses...
> With a different template you could use XDoclet to generate the descriptor
> files for Fortress/ECM/Myrmidon.
If this is possible, it seems more logical that instead the descriptor
files should be more similar...just thoughts.
> > Inital ideas are either (a) implict addition of default configuration
> > handling within Phoenix, or (b) the ability to declare an
> > alternative/pluggable configuration resolver.
>
> Technically is possible now. I could even add in plugin points to the deployer
> if you really want this right away (And you could just create a custom
> MerlinDeployer that uses CascadingConfiguration).
>
> I was going to try address it in a global manner first but if you want me to
> make it possible for you to overide default behaviour with
> CascadingConfigurerr then it should be relatively easy. Just say the word.
well, there you go. Phoenix getting there, Merlin almost there, I'm
guessing Myrmidon as well as it is also your work...seems like I have
less to think about again.
BTW, crossposting to avalon-dev as this concerns excalibur & stuff as
well.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 12:07, Stephen McConnell wrote:
> Pete:
>
> No problem with any of the proposed changes.
kool.
> I would like to see addition of support for CascadingConfigurations
> together with the addition of extensions to the .xinfo file to contain a
> default confituation declararation (which would bring Phoenix and Merlin
> almost totally in sync). Any thoughts about how this can be achieved?
A few. Currently I am working on trying to get decent interoperability between
Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has
slightly different needs there is also a bunch of common ground. Currently
the main things I am interested is getting together a single representation
of component meta data.
The types of component meta data I am thinking of is mainly;
* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is
singlethreaded etc
* context:
- Context Class
- Entrys in Context (both name of entry and type of entry)
* service:
- services required by component
* configuration/parameters:
- schema+validaiton of Configuration/Parameters
In each different container the info is represented differently. However what
I was thinking of was developing a set of standard javadoc tags and
processing the sourcefile using the XDoclet tool available at;
http://sourceforge.net/projects/xdoclet
This tool would generate the manifest files, blockinfos, possibly default
configurations and so forth in context of Phoenix/Merlin.
With a different template you could use XDoclet to generate the descriptor
files for Fortress/ECM/Myrmidon.
> Inital ideas are either (a) implict addition of default configuration
> handling within Phoenix, or (b) the ability to declare an
> alternative/pluggable configuration resolver.
Technically is possible now. I could even add in plugin points to the deployer
if you really want this right away (And you could just create a custom
MerlinDeployer that uses CascadingConfiguration).
I was going to try address it in a global manner first but if you want me to
make it possible for you to overide default behaviour with
CascadingConfigurerr then it should be relatively easy. Just say the word.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Phoenixs Deprecated features
Posted by Stephen McConnell <mc...@osm.net>.
Pete:
No problem with any of the proposed changes.
I would like to see addition of support for CascadingConfigurations
together with the addition of extensions to the .xinfo file to contain a
default confituation declararation (which would bring Phoenix and Merlin
almost totally in sync). Any thoughts about how this can be achieved?
Inital ideas are either (a) implict addition of default configuration
handling within Phoenix, or (b) the ability to declare an
alternative/pluggable configuration resolver.
Cheers, Steve.
Peter Donald wrote:
>Hi,
>
>I am slowly going through and preparing Phoenix for another release. This
>involves cleaning up bits and pieces and making sure everything that is
>supposed to work, actually works.
>
>Some of the following things are deprecated and have been for a while. I would
>like to know if anyone is using any of these features and if so tell me so
>they can be preserved.
>
>NOTE: Please send replies to the avalon-phoenix-dev mailing list so that this
>can be coordinated in one place.
>
>Heres the list of changes that I want to implement. If there is no negative
>responses by next weekend I will go ahead and do it.
>
>----------------------------------------------------------------------------------------
>Feature: Threads pools accessible from BlockContext
>Deprecated since: 2001/09/20
>
> ie The check if the following methods are used anywhere in your code.
> BlockContext.getThreadPool(String)
> BlockContext.getDefaultThreadPool()
>----------------------------------------------------------------------------------------
>Feature: BaseLogger accessible from BlockContext
>Deprecated since: Sometime before 2001/04/27
>
> ie The check if the following methods are used anywhere in your code.
> BlockContext.getBaseLogger()
>----------------------------------------------------------------------------------------
>Feature: Using elements named "block-listener" in assembly.xml
>Deprecated since: 2002/01/26
>
>ie the correct element name is <listener/> now so as not to confuse
>differences between Block and Applicaiton Listeners.
>----------------------------------------------------------------------------------------
>Feature: Using config elements named"management" to expose services as MBeans
>Was only Non-deprecated between 2002/01/12 and 2002/01/25
>
>ie the correct element name is <management-access-points/>
>----------------------------------------------------------------------------------------
>Feature: Using Service class
>Deprecated since: 2001/09/25
>
>Deprecated with no replacement.
>----------------------------------------------------------------------------------------
>Feature: Old .sar packaging format
>Deprecated since: 2001/10/22
>
>The .sar format previously allowed all blocks to be stored in
>blocks/*.bar and libraries to be stored in lib/*.zip, lib/*.jar. This has been
>changed so that all jars/libraries are stored in SAR-INF/lib/*.jar and also
>allows class files in SAR-INF/classes. The configuration files have also
>moved into SAR-INF/*.xml
>----------------------------------------------------------------------------------------
>Feature: Directly Using LogKit Logger
>Deprecated since: 2001/10/31
>
>We have been using a Logging facade (in o.a.a.framework.logger.*) for a while
>now but have had to support the old form of using the LogKit logger directly.
>Dropping support for non-facade would allow us to remove yet another
>dependenancy from deployed applications (and allow us to use JDK1.4 Logging
>where supported).
>----------------------------------------------------------------------------------------
>Feature: Use old config file name server.xml
>Deprecated since: 2001/11/10
>
>SAR-INF/server.xml was renamed to SAR-INF/environment.xml because phoenix and
>this configuration was not specific to servers but to the environment in
>which the applicaiton executes.
>----------------------------------------------------------------------------------------
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>