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