Hey
Aaron Mulder wrote:
> 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.
Ok, good.
> > 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.
Actually I was not insinuating insults. I disagree with the situation in
general, i.e. having two metadata models, and not necessarily "this one
is better than that one".
But, yes I would very much like to make a third unified model which
could be used for both server and EJX. That would make things so much
easier.
> 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.
Ah, I see. Yeah, that could work. Would be fairly easy to do even.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
