Peter Donald wrote:
>On Fri, 16 Aug 2002 14:14, [EMAIL PROTECTED] wrote:
>
>> Added: src/java/org/apache/avalon/cornerstone/blocks/connection
>> DefaultConnectionManager.xtype
>> src/java/org/apache/avalon/cornerstone/blocks/datasource
>> DefaultDataSourceSelector.xtype
>> src/java/org/apache/avalon/cornerstone/blocks/masterstore
>> RepositoryManager.xprofile RepositoryManager.xtype
>> src/java/org/apache/avalon/cornerstone/blocks/sockets
>> DefaultSocketManager.xtype
>> src/java/org/apache/avalon/cornerstone/blocks/threads
>> DefaultThreadManager.xprofile
>> DefaultThreadManager.xtype
>>
>
>-1 for *.xtype
>
>Remove all this as Merlin can read xinfo that is already generated in build
>process.
>
You *are* busy with the -1s today!
The .xtype is put in place so that these components can be used
elegantly inside Merlin. The generated xinfo does not include the
possibility for the addition of attributes which can be used by Merlin
in more advanced application scenarios. Furthermore, information about
logging categories that a component implementation required is not
available in the Phoenix varient of xinfo. Putting in place .xtype is
the viable solution while multiple schemas exist.
>
>
>-1 for *xprofile as it differs in format that phoenix will use so that will
>cause conflicts down path
>
So your saying that your -1 is the basis that you intend to use the
extension name .xprofile in the future and your not ready to work with
an exting model? Hey get real. The addition of the .xprofile happens to
be required in order to deal with blocks that implement the BlockContext
interface, and which are appropriate for declaring as packaged profiles.
If you really want to do the same thing - then just use Merlin and save
yourself some time. If you don't like that for whatever reason, then
write a builder that handles a different top-level element (just like
I'm doing to work around blockinfo limitations).
Given that neither of the points raised impact the execution of these
components in Phoenix, I fail to see what your objections is. Removal
will result in the inability to run some of these components in Merlin.
This will eliminate the possibility for running other cornerstone
components and external projects such as James which are dependent on
conerstone.
For now I'll assume your just being a tad difficult but if you have any
additional "real" objections I'm only too happy to listen to them.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
