Summary: Vince and I have discussed this and have come to a place where
things
are agreed upon.
See:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1595 for the
issue that he filed in this regard.
>>>
>>> Since every new version of the app server should support the domain.xml
>>> from older versions, either directly or through automatic invocation of
>>> the upgrade tool, you're largely trying to prevent "new" domains from
>>> being used by "old" app servers, is that correct?
>>
>>
>> yes.
>>
>>> If so, checking that
>>> the DTD/schema for the domain.xml is one of the versions supported by
>>> the app server seems like a reasonable approach.
>>
>>
>> Is there an API that does this check, or am I just going to have to
>> hope that all the assumptions will remain valid... [things like the
>> location of the dtds directory....]
>
> That I don't know.
>
> If we were validating the domain.xml, the validation framework would have
> to know how to figure out which DTD to validate it against.
As far as a given domain.xml's validation is concerned, it happens for
the first time at the
time of domain's startup. The way to start a domain is using "asadmin
start-domain".
asadmin script is "tied" to a particular application server installation and
as such it (kinda) hardcodes this knowledge. In other words, a
particular "asadmin
start-domain" invocation will validate the given domain's domain.xml
against a
particular dtd version. GF V2 and Sun Application Server 9.1 will
validate any
given domain that it starts against sun-domain_1_3.dtd. Of course, the
implicit
upgrade of the domain precedes this validation.
> Is there some
> code that does this for the Java EE deployment descriptors that you could
> reuse? If you can't find a DTD to validate it against, you would fail.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>