6:45 p.m.
Resending
Tim Fox wrote:
Jason T. Greene wrote:
> I really wish we could. Tim said theres pretty much no was JBM2 can
> make Beta1, but it could make CR1. The question is, would it be
> stable and TCK compliant enough that it doesn't end up delaying GA?
No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
That's why we can't replace JBM 1.4 in a minor release since AS minor
versions need to be compatible, and why it's being offered as a
technology preview, not replacement for default JMS provider.
>
> Dimitris Andreadis wrote:
>> Why not keep it simple and ship JBM2 in AS 5.1 Beta/CR? I suppose
>> it's a matter of dates, right?
>>
>> Jason T. Greene wrote:
>>> Because that is just configuration. Shipping just 1.4 in the
>>> community, and 1.4 and 2.0 in EAP is completely backwards from the
>>> whole upstream concept.
>>>
>>> David Ward wrote:
>>>> Why would this be weird? .com/EAP 4.x has a "production"
profile
>>>> that .org/AS 4.x does not...
>>>>
>>>> David
>>>>
>>>>
>>>> Jason T. Greene wrote:
>>>>> Part of the problem is that EAP is planning on including a JBM2
>>>>> profile / option. IMO it would be very weird to ship something in
>>>>> EAP but not in AS. Besides creating a profile, another option we
>>>>> have is to include JBM2 with an install script in docs/examples.
>>>>> Then someone could switch any AS profile to JBM2.
>>>>>
>>>>> Dimitris Andreadis wrote:
>>>>>> We have enough configurations so far, so I don't think
it's a
>>>>>> good idea adding any new ones until we come up with with a way
>>>>>> to share most of the jars/configuration.
>>>>>>
>>>>>> In your case it's better to offer the preview as a separate
>>>>>> download.
>>>>>>
>>>>>> Andy Taylor wrote:
>>>>>>> As part of the AS 5.1 release we will be shipping JBM 2.0 as
a
>>>>>>> technology preview. This will require 1 or more new profiles
to
>>>>>>> be created. I have created a branch (Branch_5_x_JBM2) to use
>>>>>>> for now which i will merge in once JBM 2.0 is released and
>>>>>>> there is something concrete and working.
>>>>>>>
>>>>>>> What new profiles we need to add is open to discussion.
We'll
>>>>>>> definitely need a copy of default as a start which could be
>>>>>>> called messaging-2. However, from a JBM2 point of view, it
>>>>>>> would be good to also demonstrate clustering which would mean
a
>>>>>>> copy of all, say messaging-2-all, and since JBM2 can run with
a
>>>>>>> minimal set of services maybe a messaging-2-minimal as well.
>>>>>>>
>>>>>>> I appreciate that adding all 3 might be too many new profiles
>>>>>>> to add so I'd like to hear peoples views!
>>>>>>>
>>>>>>> Andy Taylor Core Developer
>>>>>>> JBoss Messaging
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>
>
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
9 p.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
Tim Fox wrote:
Jason T. Greene wrote:
> I really wish we could. Tim said theres pretty much no was JBM2 can
> make Beta1, but it could make CR1. The question is, would it be
> stable and TCK compliant enough that it doesn't end up delaying GA?
No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
That's why we can't replace JBM 1.4 in a minor release since AS minor
versions need to be compatible, and why it's being offered as a
technology preview, not replacement for default JMS provider.
Where did this rule come, and what level of compatibility are we talking
about? We do need EE API compatibility, and ideally all of our public
APIs should be BC (so that developers don't have to rewrite their apps),
but IMO we don't need wire protocol compatibility. You already can't
cluster 5.1 and 5.0 together.
The insane levels of compatibility should be reserved for EAP, but 5.1
is the source of an EAP major version, so it doesn't need it.
--
Jason T. Greene
JBoss, a division of Red Hat
9:08 p.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
On 02/17/2009 02:00 PM, Jason T. Greene wrote:
Tim Fox wrote:
> Jason T. Greene wrote:
>> I really wish we could. Tim said theres pretty much no was JBM2 can
>> make Beta1, but it could make CR1. The question is, would it be
>> stable and TCK compliant enough that it doesn't end up delaying GA?
> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
> That's why we can't replace JBM 1.4 in a minor release since AS minor
> versions need to be compatible, and why it's being offered as a
> technology preview, not replacement for default JMS provider.
Where did this rule come, and what level of compatibility are we talking
about? We do need EE API compatibility, and ideally all of our public
APIs should be BC (so that developers don't have to rewrite their apps),
but IMO we don't need wire protocol compatibility. You already can't
cluster 5.1 and 5.0 together.
The insane levels of compatibility should be reserved for EAP, but 5.1
is the source of an EAP major version, so it doesn't need it.
Do we have these compatibility requirements listed somewhere? For example,
we'd have a better (still not great, but better) shot at getting Remoting 3
into EAP 5 if we didn't have to be compatible (in any way) with Remoting 2.
- DML
9:09 p.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
Tim Fox wrote:
> Jason T. Greene wrote:
>> I really wish we could. Tim said theres pretty much no was JBM2 can
>> make Beta1, but it could make CR1. The question is, would it be
>> stable and TCK compliant enough that it doesn't end up delaying GA?
> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
> That's why we can't replace JBM 1.4 in a minor release since AS minor
> versions need to be compatible, and why it's being offered as a
> technology preview, not replacement for default JMS provider.
Where did this rule come, and what level of compatibility are we talking
about? We do need EE API compatibility, and ideally all of our public
APIs should be BC (so that developers don't have to rewrite their apps),
but IMO we don't need wire protocol compatibility. You already can't
cluster 5.1 and 5.0 together.
The insane levels of compatibility should be reserved for EAP, but 5.1
is the source of an EAP major version, so it doesn't need it.
No. JMS is a client/server protocol not a server/server protocol.
If clients (and that includes legacy servers) using JBM 1.x
can't talk to jms servers using JBM 2.x
then the packages names need to be changed so that those clients
can also deploy the JBM 2.x client code alongside their own version.
Although this is not an EAP list, that requirement is more likely to
come up with EAP since we never shipped JBM by default in the
4.x community releases, while we did with EAP 4.3
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:44 p.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
Adrian Brock wrote:
On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
> Tim Fox wrote:
>> Jason T. Greene wrote:
>>> I really wish we could. Tim said theres pretty much no was JBM2 can
>>> make Beta1, but it could make CR1. The question is, would it be
>>> stable and TCK compliant enough that it doesn't end up delaying GA?
>> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
>> That's why we can't replace JBM 1.4 in a minor release since AS minor
>> versions need to be compatible, and why it's being offered as a
>> technology preview, not replacement for default JMS provider.
> Where did this rule come, and what level of compatibility are we talking
> about? We do need EE API compatibility, and ideally all of our public
> APIs should be BC (so that developers don't have to rewrite their apps),
> but IMO we don't need wire protocol compatibility. You already can't
> cluster 5.1 and 5.0 together.
>
> The insane levels of compatibility should be reserved for EAP, but 5.1
> is the source of an EAP major version, so it doesn't need it.
>
No. JMS is a client/server protocol not a server/server protocol.
Sure, but it's just an API with no required level of interoperability or
standard wire protocol. Any compatibility we offer is a feature not a
requirement of any kind.
If clients (and that includes legacy servers) using JBM 1.x
can't talk to jms servers using JBM 2.x
then the packages names need to be changed so that those clients
can also deploy the JBM 2.x client code alongside their own version.
I agree. In fact, it needs to be done anyway regardless of what version
AS includes.
Although this is not an EAP list, that requirement is more likely to
come up with EAP since we never shipped JBM by default in the
4.x community releases, while we did with EAP 4.3
I will raise that on the EAP list, we need to be sure we understand
their requirements.
--
Jason T. Greene
JBoss, a division of Red Hat
12:21 a.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
Adrian Brock wrote:
On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
> Tim Fox wrote:
>
>> Jason T. Greene wrote:
>>
>>> I really wish we could. Tim said theres pretty much no was JBM2 can
>>> make Beta1, but it could make CR1. The question is, would it be
>>> stable and TCK compliant enough that it doesn't end up delaying GA?
>>>
>> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
>> That's why we can't replace JBM 1.4 in a minor release since AS minor
>> versions need to be compatible, and why it's being offered as a
>> technology preview, not replacement for default JMS provider.
>>
> Where did this rule come, and what level of compatibility are we talking
> about? We do need EE API compatibility, and ideally all of our public
> APIs should be BC (so that developers don't have to rewrite their apps),
> but IMO we don't need wire protocol compatibility. You already can't
> cluster 5.1 and 5.0 together.
>
> The insane levels of compatibility should be reserved for EAP, but 5.1
> is the source of an EAP major version, so it doesn't need it.
>
>
No. JMS is a client/server protocol not a server/server protocol.
If clients (and that includes legacy servers) using JBM 1.x
can't talk to jms servers using JBM 2.x
then the packages names need to be changed so that those clients
can also deploy the JBM 2.x client code alongside their own version.
Yep. We've already taken that into account. JBM 2.x package names are
different to JBM 1.x package names to ensure no namespace overlap.
Although this is not an EAP list, that requirement is more likely to
come up with EAP since we never shipped JBM by default in the
4.x community releases, while we did with EAP 4.3
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
12:27 a.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
Adrian Brock wrote:
On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
> Tim Fox wrote:
>
>> Jason T. Greene wrote:
>>
>>> I really wish we could. Tim said theres pretty much no was JBM2 can
>>> make Beta1, but it could make CR1. The question is, would it be
>>> stable and TCK compliant enough that it doesn't end up delaying GA?
>>>
>> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
>> That's why we can't replace JBM 1.4 in a minor release since AS minor
>> versions need to be compatible, and why it's being offered as a
>> technology preview, not replacement for default JMS provider.
>>
> Where did this rule come, and what level of compatibility are we talking
> about? We do need EE API compatibility, and ideally all of our public
> APIs should be BC (so that developers don't have to rewrite their apps),
> but IMO we don't need wire protocol compatibility. You already can't
> cluster 5.1 and 5.0 together.
>
> The insane levels of compatibility should be reserved for EAP, but 5.1
> is the source of an EAP major version, so it doesn't need it.
>
>
No. JMS is a client/server protocol not a server/server protocol.
Ah, but the compatibility requirements go beyond JMS (that API has been
static for years as you know).
What we were told at the time was that for minor releases, EAP requires
compatibility for the JMS stuff, but also all the other stuff we add
beyond JMS (read messaging JMX interface for messaging in 1.x).
Now.... if EAP is going to consume AS community version in lock step
fashion, then it also will need the same compatibility requirements. Ouch!
If clients (and that includes legacy servers) using JBM 1.x
can't talk to jms servers using JBM 2.x
then the packages names need to be changed so that those clients
can also deploy the JBM 2.x client code alongside their own version.
Although this is not an EAP list, that requirement is more likely to
come up with EAP since we never shipped JBM by default in the
4.x community releases, while we did with EAP 4.3
--
Tim Fox
Messaging Lead
JBoss - a division of Red Hat
http://jbossfox.blogspot.com/
irc.freenode.net#jbossmessaging
fox(a)redhat.com
12:55 a.m.
New subject: Compatibility Requirements (Was Re: AS 5.1 and JBoss Messaging 2)
Tim Fox wrote:
Adrian Brock wrote:
> On Tue, 2009-02-17 at 14:00 -0600, Jason T. Greene wrote:
>
>> Tim Fox wrote:
>>
>>> Jason T. Greene wrote:
>>>
>>>> I really wish we could. Tim said theres pretty much no was JBM2 can
>>>> make Beta1, but it could make CR1. The question is, would it be
>>>> stable and TCK compliant enough that it doesn't end up delaying GA?
>>>>
>>> No, JBM 2.0 is a major release and is not compatible with JBM 1.4.
>>> That's why we can't replace JBM 1.4 in a minor release since AS
>>> minor versions need to be compatible, and why it's being offered as
>>> a technology preview, not replacement for default JMS provider.
>>>
>> Where did this rule come, and what level of compatibility are we
>> talking about? We do need EE API compatibility, and ideally all of
>> our public APIs should be BC (so that developers don't have to
>> rewrite their apps), but IMO we don't need wire protocol
>> compatibility. You already can't cluster 5.1 and 5.0 together.
>>
>> The insane levels of compatibility should be reserved for EAP, but
>> 5.1 is the source of an EAP major version, so it doesn't need it.
>>
>>
>
> No. JMS is a client/server protocol not a server/server protocol.
>
Ah, but the compatibility requirements go beyond JMS (that API has been
static for years as you know).
What we were told at the time was that for minor releases, EAP requires
compatibility for the JMS stuff, but also all the other stuff we add
beyond JMS (read messaging JMX interface for messaging in 1.x).
Now.... if EAP is going to consume AS community version in lock step
fashion, then it also will need the same compatibility requirements. Ouch!
See the still ongoing EAP compatibility discussion on core. The short
answer is that it's not required between major versions (provided there
is a migration guide). Therefore we can break it in 5.1, since it's the
first EAP 5 release. Any future 5.x release though will have to be more
careful.
--
Jason T. Greene
JBoss, a division of Red Hat
5553
days inactive
5553
days old
jboss-development@lists.jboss.org
7 comments
4 participants
participants (4)
-
Adrian Brock -
David M. Lloyd -
Jason T. Greene -
Tim Fox