[wildfly-dev] Support for legacy xml parsers

[James R. Perkins]

That's actually a good point I hadn't considered.

I can't speak for other subsystems, but logging would still be useful. 
There are more resources now and probably better ways to do things, but 
the old operations and resources are still there. For me they're not all 
that hard to maintain.

On 07/24/2014 01:12 PM, Brian Stansberry wrote:
> Is a 7.1.1 config file likely to be useful in WF 9? On a server we no
> longer support the old web subsystem, cmp and jaxr. By the time we're
> done with Elytron integration, the security subsystem may be completely
> revamped as well, with the current config relegated to HC-only support
> for use in a mixed domain.
>
> On 7/24/14, 11:11 AM, James R. Perkins wrote:
>> Ha, I just saw this email after having a conversion with Tomaz and David
>> on IRC.
>>
>> Since WildFly there was such a long time between 7.1.1.Final and WildFly
>> 8 I think it might be better to wait until WildFly 10. I still see quite
>> a few questions regarding JBoss AS 7.x. If we could encourage those
>> users to switch to WildFly I think it would make all of us happier :) If
>> we cut support for WildFly 9 of their configuration files I could see
>> them less likely to move if 9 is the current release.
>>
>> On 07/24/2014 08:50 AM, Brian Stansberry wrote:
>>> For WildFly 9 (not 8.2) I propose that we change our policy regarding
>>> support for legacy WildFly configuration documents.[1]
>>>
>>> Currently we support being able to parse content from any of our
>>> namespaces (core or subsystem) shipped in a final release going back to
>>> AS 7.0.0.
>>>
>>> I want to change this to limit support to namespaces shipped in AS 7.2.0
>>> or later and EAP 6.1.0 or later.
>>>
>>> This cutoff is consistent with what we are doing with mixed-version
>>> support in managed domains.
>>>
>>> The goal of this is to reduce the maintenance burden related to legacy
>>> xml parsers. The goal is *not* to reduce the size of the codebase etc.
>>> So, if this proposal carries, please do not go off and delete old stuff
>>> that works just because you can. But, if you find yourself having to
>>> expend energy maintaining one of these old parsers, the policy change
>>> means just dropping it is a valid alternative.
>>>
>>> Comments?
>>>
>>>
>>> [1] Configuration documents meaning standalone/domain/host.xml, not
>>> stuff like deployment descriptors.
>>>
>

-- 
James R. Perkins
JBoss by Red Hat