<div dir="ltr"><div>We could just have special handling for loading this legacy sub extensions.<br>Given that they matter only for domain controller and not for everything else it could be done.<br><br></div>How domain controller loads this stub stuff, should not matter to 7.2 HC, <br>
as long it as comes in format that it can digest.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 1, 2013 at 9:48 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure how the ServiceLoader part would work there. At least not<br>
with what I imagine when I think of an "alias." With some kind of stub<br>
where each has a different<br>
META-INF/services/org.jboss.as.controller.Extension file it could work.<br>
<div class="HOEnZb"><div class="h5"><br>
On 3/1/13 2:29 PM, David M. Lloyd wrote:<br>
> Yeah, I was thinking they could just be aliases or stubs though.<br>
><br>
> On 03/01/2013 02:22 PM, Brian Stansberry wrote:<br>
>> In terms of code organization, perhaps. But the way the extension is<br>
>> activated in the HCs and servers is via the module name. So if you want<br>
>> a 7.2 server to be able to run CMP, there is going to have to be a<br>
>> module named org.jboss.as.cmp.<br>
>><br>
>> On 3/1/13 2:13 PM, David M. Lloyd wrote:<br>
>>> I wonder - should we retain a skeletal version of each of these modules?<br>
>>> I was thinking maybe it would be better to maintain one big<br>
>>> "removed-subsystems" or "compat-subsystems" module or something like<br>
>>> that where we can neatly/consistently organize all the model stuff for<br>
>>> these removals.<br>
>>><br>
>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:<br>
>>>> Thanks Thomas, for raising this and for the JIRA.<br>
>>>><br>
>>>> I've outlined what I think is needed for the stub extensions as a<br>
>>>> comment on <a href="https://issues.jboss.org/browse/AS7-6656" target="_blank">https://issues.jboss.org/browse/AS7-6656</a> .<br>
>>>><br>
>>>> Can I request that folks hold up on deleting these subsystems? I think<br>
>>>> it will be easier to make these changes and then delete the unneeded<br>
>>>> runtime stuff than it will be to semi-restore from history and then change.<br>
>>>><br>
>>>> The ones that have already been deleted, it's no big deal.<br>
>>>><br>
>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:<br>
>>>>> Ok, stub extensions is the obvious alternative to breaking compatibility. I'll leave this as a future task and create a jira for it if that's ok with you.<br>
>>>>><br>
>>>>> cheers<br>
>>>>> --thomas<br>
>>>>><br>
>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br>
>>>>><br>
>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:<br>
>>>>>>> Folks,<br>
>>>>>>><br>
>>>>>>> related to<br>
>>>>>>><br>
>>>>>>> * [AS7-6612 <<a href="https://issues.jboss.org/browse/AS7-6612" target="_blank">https://issues.jboss.org/browse/AS7-6612</a>>] Remove JAXR support<br>
>>>>>>><br>
>>>>>>> I'd like to know whether we need to preserve backward compatibility of<br>
>>>>>>> the configuration and if so what should happen if there is a jaxr config<br>
>>>>>>> item? Generally, can AS8 break backward compatibility with respect to<br>
>>>>>>> the config?<br>
>>>>>><br>
>>>>>> Brian points out that we don't have a specific requirement to maintain<br>
>>>>>> compatibility with obsolete subsystems. I think we could go ahead with<br>
>>>>>> the removal (granted part of the reason I feel this way is that I've<br>
>>>>>> already removed JSR-88...).<br>
>>>>>><br>
>>>>>> Going forward though Kabir suggested that if we do want to, say, allow<br>
>>>>>> 7.x instances to be managed from an 8.x DC, that we should create "stub"<br>
>>>>>> extensions for the removed stuff that only carry and validate<br>
>>>>>> configuration but aren't actually supported on 8.x servers. This seems<br>
>>>>>> like a valid possibility to me.<br>
>>>>>> --<br>
>>>>>> - DML<br>
>>>>>> _______________________________________________<br>
>>>>>> jboss-as7-dev mailing list<br>
>>>>>> <a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
>>>>><br>
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
>>>>> Thomas Diesler<br>
>>>>> JBoss OSGi Lead<br>
>>>>> JBoss, a division of Red Hat<br>
>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> jboss-as7-dev mailing list<br>
>>>>> <a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>><br>
>><br>
><br>
><br>
<br>
<br>
--<br>
</div></div><div class="im HOEnZb">Brian Stansberry<br>
Principal Software Engineer<br>
JBoss by Red Hat<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
jboss-as7-dev mailing list<br>
<a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
</div></div></blockquote></div><br></div>