Peter Royal wrote:
>On Friday 16 August 2002 07:22 am, Stephen McConnell wrote:
>
>
>>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.
>>
>>
>
>Are there plans for xdoclet generation of the xinfo files?
>
>
It's on the "wish list" but not on my "must-be-done" list. I'm
basically focussing on getting in place all of the fundimental
necessiries for a really solid embeddable container. Based on the
additions from Berin things are now looking reasonably complete - about
the only things I want to do before goinf to Alpha is to go over the
meta-info model in detail at theb API level and make sure I'm really
happy with it. After that I will prose a package renaming and do the
seperation of non-container-specific content into seperate projects.
Once that is done I will be focussing on a real application that will
be using Merlin extensively for embedeed process management, dynamic
loading of components, and dynamic container management and navigation.
>Perhaps we could reach agreement at that level (xdoclet markup). Having the
>logging categories a component expects is usefull information for phoenix, it
>would be very nice to generate a default environment.xml using such
>information.
>-pete
>
>
To ensure compatibility at the markup level between block-info and type
there is one item that would be needed in the Type schema - namely the
management assess point definitions. JMX support is something that has
been requested from three sources already, but I'm feeling a little bit
hesitant about defining the meta-model for this because my JMX API
knowlege is a little thin. Aside from that point, I aware of the
priorities to get Phoenix out as a release and I don't want to hold that
up. The ideal scenario is that an common meta-info API and DTD are
adopted. If you get down to nuts-and-bolts, there really are not any
issues here. The meta-info models are for all practical purposes the
same with the following exceptions:
* that the Type model allows the association of a default
configuration (which is drop-dead-simple to implement).
* the Type model includes Stage and Extension declarations (which can
used by Phoenix to throw out the type)
If we get in place a common meta-info model, then we will have Merlin
and Fortress componets runnable in Phoinix, Phoenix componets runnable
in Merlin and Fortress, etc. provding extension are not used - and even
if they are - its totally feasible to embedd Merlin inside the Phoenix
kernel and let it handle these special cases.
But as a first-step - a common xdoclet approach would be very cool -
people over in the Fortress and James worlds have been asking for it.
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]>
