>
>
>>Short-term, parsing twice does not seem too bad here...
>>
>
>maybe to you, it sounds disasterous to me.
>
How so?
>I think that we might want to "do away" with the .sar format as we know
>it... we can figure out how to deal with native libraries and canned
>file systems later.
>
>
>Why? And what do you mean "as we know it? What do you want instead,
>exactly? What capabilities will it have?
>
Forget about the format for now and revist later. Basically, stop using
.sar and convert all current .sar deployments into .jar + .xml
>That would be fine with me. I don't think marc has given up on having some
>kind of "wait for my class" dependency checking, I think it was the
>particular multi-threaded implementation with blocking that he gave up on.
>
That is probably best then... short term at least.
>I strongly object to parsing xml into metadata objects and then
>transferring the metadata to the real objects in another step. IMNSHO this
>is ridiculous as a model. I support parsing the xml directly into the
>configuration of the actual objects that you will use to do the work. This
>is what the current ServiceConfigurator does for mbeans.
>
There are several reason why it would be a good idea to generate a model
from xml and use that model for configuration:
o Isolates XML stuff from configuration, such that one does not need
XML to configure with. This leaves
logic components unaware of the details of validating the
configuration and frees it to focus on the problem
which it solves.
o Allows uniform validation and data transformation. Such as
implementing the whitespace trim unless nested
in a CDATA block, peforming property subst on attribute values.
o Prevents any duplicate parsing when configuration data is needed at
different stages. For example
ServiceConfigurator works directly off of XML tree to invoke methods
on MBeanServer, so anything that
needs configuraiton before we have registered the component in the
MBeanServer will need to walk the
tree before it does.
o Allows replacement marshal/unmarshalling system to be dropped in with
minimal integration effort.
o Allows configuration of the system where XML is not available or desired.
>IMO we can use
>JAXB or Castor or ?? to do the same with ejb configuration, thus completely
>eliminating the metadata classes.
>
This would tie the config to XML, which isn't a good idea. Better to
abstract this. For example, assume there is a simple interface for
jboss-service.xml, root level might look like this:
public interface ServiceConfig
{
// classpath elements
void addClasspath(String codebase, String archives);
void addClasspath(Classpath path);
Iterator getClasspath();
// mbean elements
// ...
}
// ...
ServiceConfig config = UnmarshalFromXml(inputStream); // or whatever
// Ensure required classpath
Iterator iter = config.getClasspath();
while (iter.hasNext())
{
Classpath path = (Classpath)iter.next();
// do check/install with ServiceLibraries
}
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
