<div dir="ltr"><div><div>What about if we just use legacy extensions that would be loaded only on DC?<br></div>for legacy i mean, why not just have modules / jars from 7.2 in 8.0 distro?<br>that would make it easiest to support, and no extra work.<br>
</div>We should just put them in some special place in distro, <br>so it would be obvious that is legacy stuff only DC uses...<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 1, 2013 at 11:44 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">The extension registration logic would have to be altered to not barf<br>
when multiple aliases all try to register the same extensions/ subsystems.<br>
<br>
But it probably should still barf if a user tried to do that for some<br>
other reason. So which is happening needs to be clarified.<br>
<br>
A way to do that is to use something other than<br>
org.jboss.as.controller.Extension for the ServiceLoader (i.e. first try<br>
ServiceLoader for "LegacyExtension" and then if not there try for<br>
org.jboss.as.controller.Extension.) That's hacky though unless there is<br>
a real difference in the service API between Extension and what these<br>
legacy extensions do. AFAICT though, there is no API difference;<br>
difference is only in impl.<br>
<div class="HOEnZb"><div class="h5"><br>
On 3/1/13 4:23 PM, David M. Lloyd wrote:<br>
> Rewinding the discussion a bit :)<br>
><br>
> If we just had one compat module (with N pure aliases), it could easily<br>
> register all the subsystems for all the modules at that time (subsystem<br>
> registration is pretty lightweight these days, or so it seems at a<br>
> glance). If extra subsystems are available as a result of an extension<br>
> reg I don't see that as harmless.<br>
><br>
> On 03/01/2013 02:48 PM, Brian Stansberry wrote:<br>
>> 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>
>><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>
><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>