<div dir="ltr"><div><div><div>that is why i would suggest packaging this modules in special folder <br>under our distribution that would only be accessible by domain controller itself.<br><br></div><div>This way we make sure this modules only operate in MODEL stage.<br>

</div><div><br></div>Sure noting stops user from moving this modules to some other folder, <br>but he could also copy them from older version....<br><br></div>Other option would be to do model version checking, aka if module name is org.jboss.as.*<br>

and major version is &lt; 2 we would not allow runtime stage to be executed.<br></div>That brings some more complexity and forces us to bump major version for all subsystems<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Mar 2, 2013 at 12:15 AM, Brian Stansberry <span dir="ltr">&lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I say &quot;find problems&quot; I don&#39;t mean management problems. I mean runtime service bugs. If we ship the 7.2 CMP module and someone runs it on an AS8 server and reports an EJBQL parsing bug, how do we respond?<div class="im">
<br>
<br>
On 3/1/13 5:07 PM, Tomaž Cerar wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
hmm, given that DC only operates on MODEL/ADMIN  stage<br>
there should no big issues if we make sure our model driven api is<br>
compatible also in AS8.<br>
I think that would be mostly jboss-as-controller and maybe few more.<br>
But before I speculate, I should test my theory...<br>
--<br>
tomaz<br>
<br>
<br>
On Fri, Mar 1, 2013 at 11:55 PM, Brian Stansberry<br></div><div class="im">
&lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a> &lt;mailto:<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@<u></u>redhat.com</a>&gt;&gt; wrote:<br>

<br>
    They have to have logic that prevents their use on an AS8 server.<br>
    Unless we are willing to tell folks who use them on AS8 servers and<br>
    find problems that they&#39;re out of luck and should know better.<br>
<br>
<br>
    On 3/1/13 4:49 PM, Tomaž Cerar wrote:<br>
<br>
        What about if we just use legacy extensions that would be loaded<br>
        only on DC?<br>
        for legacy i mean, why not just have modules / jars from 7.2 in<br>
        8.0 distro?<br>
        that would make it easiest to support, and no extra work.<br>
        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>
<br>
<br>
        On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry<br>
        &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a><br>
        &lt;mailto:<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@<u></u>redhat.com</a>&gt;<br></div>
        &lt;mailto:<a href="mailto:brian.stansberry@" target="_blank">brian.stansberry@</a>__<a href="http://redhat.com" target="_blank">red<u></u>hat.com</a><div class="im"><br>
        &lt;mailto:<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@<u></u>redhat.com</a>&gt;&gt;&gt; wrote:<br>
<br>
             The extension registration logic would have to be altered<br>
        to not barf<br>
             when multiple aliases all try to register the same extensions/<br>
             subsystems.<br>
<br>
             But it probably should still barf if a user tried to do<br>
        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></div>
             org.jboss.as.controller.__<u></u>Extension for the ServiceLoader<div class="im"><br>
        (i.e. first try<br>
             ServiceLoader for &quot;LegacyExtension&quot; and then if not there<br>
        try for<br></div>
             org.jboss.as.controller.__<u></u>Extension.) That&#39;s hacky though<div><div class="h5"><br>
        unless there is<br>
             a real difference in the service API between Extension and<br>
        what these<br>
             legacy extensions do. AFAICT though, there is no API<br>
        difference;<br>
             difference is only in impl.<br>
<br>
             On 3/1/13 4:23 PM, David M. Lloyd wrote:<br>
              &gt; Rewinding the discussion a bit :)<br>
              &gt;<br>
              &gt; If we just had one compat module (with N pure aliases),<br>
        it could<br>
             easily<br>
              &gt; register all the subsystems for all the modules at that time<br>
             (subsystem<br>
              &gt; registration is pretty lightweight these days, or so it<br>
        seems at a<br>
              &gt; glance).  If extra subsystems are available as a result<br>
        of an<br>
             extension<br>
              &gt; reg I don&#39;t see that as harmless.<br>
              &gt;<br>
              &gt; On 03/01/2013 02:48 PM, Brian Stansberry wrote:<br>
              &gt;&gt; I&#39;m not sure how the ServiceLoader part would work<br>
        there. At<br>
             least not<br>
              &gt;&gt; with what I imagine when I think of an &quot;alias.&quot; With<br>
        some kind<br>
             of stub<br>
              &gt;&gt; where each has a different<br></div></div>
              &gt;&gt; META-INF/services/org.jboss.__<u></u>as.controller.Extension<div><div class="h5"><br>
        file it<br>
             could work.<br>
              &gt;&gt;<br>
              &gt;&gt; On 3/1/13 2:29 PM, David M. Lloyd wrote:<br>
              &gt;&gt;&gt; Yeah, I was thinking they could just be aliases or<br>
        stubs though.<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt; On 03/01/2013 02:22 PM, Brian Stansberry wrote:<br>
              &gt;&gt;&gt;&gt; In terms of code organization, perhaps. But the way the<br>
             extension is<br>
              &gt;&gt;&gt;&gt; activated in the HCs and servers is via the module<br>
        name. So if<br>
             you want<br>
              &gt;&gt;&gt;&gt; a 7.2 server to be able to run CMP, there is going to<br>
        have to be a<br>
              &gt;&gt;&gt;&gt; module named org.jboss.as.cmp.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; On 3/1/13 2:13 PM, David M. Lloyd wrote:<br>
              &gt;&gt;&gt;&gt;&gt; I wonder - should we retain a skeletal version of<br>
        each of<br>
             these modules?<br>
              &gt;&gt;&gt;&gt;&gt;        I was thinking maybe it would be better to<br>
        maintain<br>
             one big<br>
              &gt;&gt;&gt;&gt;&gt; &quot;removed-subsystems&quot; or &quot;compat-subsystems&quot; module or<br>
             something like<br>
              &gt;&gt;&gt;&gt;&gt; that where we can neatly/consistently organize all<br>
        the model<br>
             stuff for<br>
              &gt;&gt;&gt;&gt;&gt; these removals.<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt; On 03/01/2013 09:39 AM, Brian Stansberry wrote:<br>
              &gt;&gt;&gt;&gt;&gt;&gt; Thanks Thomas, for raising this and for the JIRA.<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt; I&#39;ve outlined what I think is needed for the stub<br>
        extensions<br>
             as a<br>
              &gt;&gt;&gt;&gt;&gt;&gt; comment on<br></div></div>
        <a href="https://issues.jboss.org/__browse/AS7-6656" target="_blank">https://issues.jboss.org/__<u></u>browse/AS7-6656</a><div class="im"><br>
        &lt;<a href="https://issues.jboss.org/browse/AS7-6656" target="_blank">https://issues.jboss.org/<u></u>browse/AS7-6656</a>&gt; .<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt; Can I request that folks hold up on deleting these<br>
             subsystems? I think<br>
              &gt;&gt;&gt;&gt;&gt;&gt; it will be easier to make these changes and then<br>
        delete the<br>
             unneeded<br>
              &gt;&gt;&gt;&gt;&gt;&gt; runtime stuff than it will be to semi-restore from<br>
        history<br>
             and then change.<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt; The ones that have already been deleted, it&#39;s no<br>
        big deal.<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt; On 2/28/13 10:35 AM, Thomas Diesler wrote:<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; Ok, stub extensions is the obvious alternative to<br>
        breaking<br>
             compatibility. I&#39;ll leave this as a future task and create<br>
        a jira<br>
             for it if that&#39;s ok with you.<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; cheers<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; --thomas<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; On Feb 28, 2013, at 4:22 PM, David M. Lloyd<br>
             &lt;<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a> &lt;mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><u></u>&gt;<br></div>
        &lt;mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><div class="im"><br>
        &lt;mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a><u></u>&gt;__&gt;&gt; wrote:<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On 02/28/2013 05:57 AM, Thomas Diesler wrote:<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Folks,<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; related to<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; * [AS7-6612<br></div>
        &lt;<a href="https://issues.jboss.org/__browse/AS7-6612" target="_blank">https://issues.jboss.org/__<u></u>browse/AS7-6612</a><div><div class="h5"><br>
        &lt;<a href="https://issues.jboss.org/browse/AS7-6612" target="_blank">https://issues.jboss.org/<u></u>browse/AS7-6612</a>&gt;&gt;]<br>
             Remove JAXR support<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I&#39;d like to know whether we need to preserve<br>
        backward<br>
             compatibility of<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the configuration and if so what should happen<br>
        if there<br>
             is a jaxr config<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; item? Generally, can AS8 break backward<br>
        compatibility<br>
             with respect to<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the config?<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Brian points out that we don&#39;t have a specific<br>
        requirement<br>
             to maintain<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; compatibility with obsolete subsystems.  I think<br>
        we could<br>
             go ahead with<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the removal (granted part of the reason I feel<br>
        this way is<br>
             that I&#39;ve<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; already removed JSR-88...).<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Going forward though Kabir suggested that if we<br>
        do want<br>
             to, say, allow<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; 7.x instances to be managed from an 8.x DC, that<br>
        we should<br>
             create &quot;stub&quot;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; extensions for the removed stuff that only carry<br>
        and validate<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; configuration but aren&#39;t actually supported on 8.x<br>
             servers.  This seems<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; like a valid possibility to me.<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; --<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; - DML<br></div></div>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ______________________________<u></u>___________________<div class="im"><br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; jboss-as7-dev mailing list<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;<br></div>
             &lt;mailto:<a href="mailto:jboss-as7-dev@lists." target="_blank">jboss-as7-dev@lists.</a>__<a href="http://jboss.org" target="_blank"><u></u>jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;&gt;<br>
<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
        <a href="https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/__<u></u>mailman/listinfo/jboss-as7-dev</a><div class="im"><br>
        &lt;<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/jboss-as7-dev</a><u></u>&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; xxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; Thomas Diesler<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; JBoss OSGi Lead<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; JBoss, a division of Red Hat<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; xxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br></div>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; ______________________________<u></u>___________________<div class="im"><br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; jboss-as7-dev mailing list<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;<br></div>
             &lt;mailto:<a href="mailto:jboss-as7-dev@lists." target="_blank">jboss-as7-dev@lists.</a>__<a href="http://jboss.org" target="_blank"><u></u>jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;&gt;<br>
<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
        <a href="https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/__<u></u>mailman/listinfo/jboss-as7-dev</a><div class="im"><br>
        &lt;<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/jboss-as7-dev</a><u></u>&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;&gt;<br>
              &gt;&gt;<br>
              &gt;&gt;<br>
              &gt;<br>
              &gt;<br>
<br>
<br>
             --<br>
             Brian Stansberry<br>
             Principal Software Engineer<br>
             JBoss by Red Hat<br></div>
             ______________________________<u></u>___________________<div class="im"><br>
             jboss-as7-dev mailing list<br>
        <a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;<br></div>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists." target="_blank">jboss-as7-dev@lists.</a>__<a href="http://jboss.org" target="_blank"><u></u>jboss.org</a><br>
        &lt;mailto:<a href="mailto:jboss-as7-dev@lists.jboss.org" target="_blank">jboss-as7-dev@lists.<u></u>jboss.org</a>&gt;&gt;<br>
        <a href="https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/__<u></u>mailman/listinfo/jboss-as7-dev</a><div class="im"><br>
        &lt;<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/jboss-as7-dev</a><u></u>&gt;<br>
<br>
<br>
<br>
<br>
    --<br>
    Brian Stansberry<br>
    Principal Software Engineer<br>
    JBoss by Red Hat<br>
<br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
Brian Stansberry<br>
Principal Software Engineer<br>
JBoss by Red Hat<br>
</div></div></blockquote></div><br></div>