On Tue, 24 Oct 2000, Rickard Oberg wrote:
> Nope, I think it would be better to add this to
> org.jboss.ejb.deployment.JRMPContainerInvokerConfiguration where it belongs.
> What this corresponds to in the "metadata" package I don't know.
Okay, no problem. It looks like JRMPContainerInvoker loads its
content directly from the XML Element in the new MetaData scheme, so that
should be a trivial fix. I'll go ahead. I'll make it default to
anonymous ports if the tag is not present, so you only specify it if you
have something to specify.
> Here we begin seeing the problem of having two metadata models. I will not
> say anything, but you know my opinion on this one...
Well, you know my opinion on the old model. Perhaps instead of
insinuating insults, we could all work together to design a newer, better,
unified metadata scheme.
I like the general approach of the new model better, but I wish
the metadata classes would hold all the metadata instead of having
"metadata clients" like the container invoker load their information
directly from the XML tree. Perhaps an XML tree is one of the better ways
of representing an unknown set of tags for the dynamic clients (e.g. the
instaces loaded by a reference on one tag that then need to process the
data specific to them in other tags). On the other hand, it may be better
to restructure the XML to be more like this:
<container-invoker class="foo">
<param name="port" value="4444" />
<param name="optimized" value="true" />
</container-invoker>
That way we can create a fixed metadata object for the container
invoker, with a class name and a Map of options, and we can have a
fixed DTD that we can validate against even if you use a previously
unknown container invoker with different required options.
Aaron
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
