You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Arjun Panday <ar...@alcatel-lucent.fr> on 2009/02/24 12:47:47 UTC
the case of not backward compatible API
Imagine we have, in the same JVM :
- API 1.0
- API 1.1
- an implementation bundle for the 1.0 version of the API
- an implementation bundle for the 1.1 version of the API
- a client imports API;version="1.0"
- a client imports API;version="1.1"
API 1.1 is NOT backward compatible with 1.0 (same classes but
differences in methods signatures)
In spite of the differences, both implementations share the same code
base (based on v1.0); that is, implementation 1.1 extends (imports)
common code from implementation 1.0
(we could move the common code to a separate bundle, but the problem
remains)
The question is how do we avoid linkage errors? (and avoid duplicating
the common code!) :
the common code and 1.0 implementation are wired to API 1.0, but the 1.1
implementation will be wired to the 1.1 API AND to the 1.0 API (for the
common code)
Any suggestion?
Thanks,
/Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: the case of not backward compatible API
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
So far so good..
what i meant more precisely is that "util" is the implementation of the
stable part of the API.. and it has methods that take the API's object
as parameters..
let's say:
servlet API v1:
com.servlet.Request
com.servlet.Servlet
=> public void doRequest(Request)
com.servlet.Context
=> public void setServlet(Servlet)
servlet API v11:
com.servlet.Request
com.servlet.Servlet
=> public void doRequest(Request, String param)
com.servlet.Context
=> public void setServlet(Servlet)
impl v1:
util.RequestImpl implements Request (v1)
util.ContextImpl implements Context (v1)
implem1.ServletImpl implements Servlet (v1)
impl v11:
implem11.ServletImpl implements Servlet (v11)
Most of the API (here Request and Context) has not changed and neither
has the implementation. But then at runtime, implv11 will pass a v11
version of Servlet to the setServlet() method of Context...
(Am i making any sense or am i just confused?!)
Honestly, the question arose as a theoretical one and we're not blocked
in a real life issue for now.
Now after discussion with a colleague, his opinion is that it's simply a
packaging issue to duplicate the util class files (for RequestImpl and
ContextImpl) in both implementation bundles without duplicating the
actual source code... and i tend to agree with him, as I do not see an
option to totally avoid duplication.
What do you think?
/Arjun
Richard S. Hall wrote:
> I don't see any issues here. Just make sure you have your import
> ranges properly scoped for the packages you need.
>
> For example:
>
> APIv1: export api;version=1.0
> APIv11: export api;version=1.1
> IMPLv1: export util;version=1.0, import api;version[1.0,1.0]
> IMPLv11: import api;version=[1.1,1.1],util;version=[1.0,1.0]
> CLIENTv1: import api;version=[1.0,1.0]
> CLIENTv11: import api;version=[1.1,1.1]
>
> -> richard
>
> Arjun Panday wrote:
>> Imagine we have, in the same JVM :
>> - API 1.0
>> - API 1.1
>> - an implementation bundle for the 1.0 version of the API
>> - an implementation bundle for the 1.1 version of the API
>> - a client imports API;version="1.0"
>> - a client imports API;version="1.1"
>>
>> API 1.1 is NOT backward compatible with 1.0 (same classes but
>> differences in methods signatures)
>> In spite of the differences, both implementations share the same code
>> base (based on v1.0); that is, implementation 1.1 extends (imports)
>> common code from implementation 1.0
>> (we could move the common code to a separate bundle, but the problem
>> remains)
>>
>> The question is how do we avoid linkage errors? (and avoid
>> duplicating the common code!) :
>> the common code and 1.0 implementation are wired to API 1.0, but the
>> 1.1 implementation will be wired to the 1.1 API AND to the 1.0 API
>> (for the common code)
>>
>> Any suggestion?
>>
>> Thanks,
>> /Arjun
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: the case of not backward compatible API
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Arjun Panday wrote:
> (i'm sending this a second time.. it seems that it never went
> through... please apologize if you get it twice!)
You need to subscribe to the mailing list so your messages don't require
moderation.
-> richard
>
>
> Rick,
> I agree so far.
>
> What i meant more precisely is that "util" is the implementation of the
> stable part of the API.. and it has methods that take the API's object
> as parameters..
>
> let's say:
> servlet API v1:
> com.servlet.Request
> com.servlet.Servlet
> => public void doRequest(Request)
> com.servlet.Context
> => public void setServlet(Servlet)
>
> servlet API v11:
> com.servlet.Request
> com.servlet.Servlet
> => public void doRequest(Request, String param)
> com.servlet.Context
> => public void setServlet(Servlet)
>
> impl v1:
> util.RequestImpl implements Request (v1)
> util.ContextImpl implements Context (v1)
> implem1.ServletImpl implements Servlet (v1)
>
> impl v11:
> implem11.ServletImpl implements Servlet (v11)
>
> Most of the API (here Request and Context) has not changed and neither
> has the implementation. But then at runtime, implv11 will pass a v11
> version of Servlet to the setServlet() method of Context...
>
> (Am i making any sense or am i just confused?!)
> Honestly, the question arose as a theoretical one and we're not blocked
> in a real life issue for now.
> Now after discussion with a colleague, his opinion is that it's simply a
> packaging issue to duplicate the util class files (for RequestImpl and
> ContextImpl) in both implementation bundles without duplicating the
> actual source code... and i tend to agree with him, as I do not see an
> option to totally avoid duplication.
> What do you think?
>
>
> /Arjun
>
>
>
> Richard S. Hall wrote:
>> I don't see any issues here. Just make sure you have your import
>> ranges properly scoped for the packages you need.
>>
>> For example:
>>
>> APIv1: export api;version=1.0
>> APIv11: export api;version=1.1
>> IMPLv1: export util;version=1.0, import api;version[1.0,1.0]
>> IMPLv11: import api;version=[1.1,1.1],util;version=[1.0,1.0]
>> CLIENTv1: import api;version=[1.0,1.0]
>> CLIENTv11: import api;version=[1.1,1.1]
>>
>> -> richard
>>
>> Arjun Panday wrote:
>>> Imagine we have, in the same JVM :
>>> - API 1.0
>>> - API 1.1
>>> - an implementation bundle for the 1.0 version of the API
>>> - an implementation bundle for the 1.1 version of the API
>>> - a client imports API;version="1.0"
>>> - a client imports API;version="1.1"
>>>
>>> API 1.1 is NOT backward compatible with 1.0 (same classes but
>>> differences in methods signatures)
>>> In spite of the differences, both implementations share the same
>>> code base (based on v1.0); that is, implementation 1.1 extends
>>> (imports) common code from implementation 1.0
>>> (we could move the common code to a separate bundle, but the problem
>>> remains)
>>>
>>> The question is how do we avoid linkage errors? (and avoid
>>> duplicating the common code!) :
>>> the common code and 1.0 implementation are wired to API 1.0, but the
>>> 1.1 implementation will be wired to the 1.1 API AND to the 1.0 API
>>> (for the common code)
>>>
>>> Any suggestion?
>>>
>>> Thanks,
>>> /Arjun
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: the case of not backward compatible API
Posted by Arjun Panday <ar...@alcatel-lucent.fr>.
(i'm sending this a second time.. it seems that it never went through...
please apologize if you get it twice!)
Rick,
I agree so far.
What i meant more precisely is that "util" is the implementation of the
stable part of the API.. and it has methods that take the API's object
as parameters..
let's say:
servlet API v1:
com.servlet.Request
com.servlet.Servlet
=> public void doRequest(Request)
com.servlet.Context
=> public void setServlet(Servlet)
servlet API v11:
com.servlet.Request
com.servlet.Servlet
=> public void doRequest(Request, String param)
com.servlet.Context
=> public void setServlet(Servlet)
impl v1:
util.RequestImpl implements Request (v1)
util.ContextImpl implements Context (v1)
implem1.ServletImpl implements Servlet (v1)
impl v11:
implem11.ServletImpl implements Servlet (v11)
Most of the API (here Request and Context) has not changed and neither
has the implementation. But then at runtime, implv11 will pass a v11
version of Servlet to the setServlet() method of Context...
(Am i making any sense or am i just confused?!)
Honestly, the question arose as a theoretical one and we're not blocked
in a real life issue for now.
Now after discussion with a colleague, his opinion is that it's simply a
packaging issue to duplicate the util class files (for RequestImpl and
ContextImpl) in both implementation bundles without duplicating the
actual source code... and i tend to agree with him, as I do not see an
option to totally avoid duplication.
What do you think?
/Arjun
Richard S. Hall wrote:
> I don't see any issues here. Just make sure you have your import
> ranges properly scoped for the packages you need.
>
> For example:
>
> APIv1: export api;version=1.0
> APIv11: export api;version=1.1
> IMPLv1: export util;version=1.0, import api;version[1.0,1.0]
> IMPLv11: import api;version=[1.1,1.1],util;version=[1.0,1.0]
> CLIENTv1: import api;version=[1.0,1.0]
> CLIENTv11: import api;version=[1.1,1.1]
>
> -> richard
>
> Arjun Panday wrote:
>> Imagine we have, in the same JVM :
>> - API 1.0
>> - API 1.1
>> - an implementation bundle for the 1.0 version of the API
>> - an implementation bundle for the 1.1 version of the API
>> - a client imports API;version="1.0"
>> - a client imports API;version="1.1"
>>
>> API 1.1 is NOT backward compatible with 1.0 (same classes but
>> differences in methods signatures)
>> In spite of the differences, both implementations share the same code
>> base (based on v1.0); that is, implementation 1.1 extends (imports)
>> common code from implementation 1.0
>> (we could move the common code to a separate bundle, but the problem
>> remains)
>>
>> The question is how do we avoid linkage errors? (and avoid
>> duplicating the common code!) :
>> the common code and 1.0 implementation are wired to API 1.0, but the
>> 1.1 implementation will be wired to the 1.1 API AND to the 1.0 API
>> (for the common code)
>>
>> Any suggestion?
>>
>> Thanks,
>> /Arjun
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: the case of not backward compatible API
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Arjun,
It sounds like you want the "util" part of the implementation to see two
different versions of the API package at the same time. This is not
possible. The reality in your example below is that your bundle v1
bundle is wired to the v1 API. You can not use it in another bundle that
is wired to v11 of the same API, otherwise those clases we be seeing to
different versions of the same package at the same time.
There is no way you can do what you want, which is to have one bundle
that implements common parts of different versions of the API. I
suppose, you could break the API into changed and non-changed parts, but
this would lead to strange versioning and confusion.
-> richard
APIv1: export api;version
Arjun Panday wrote:
> Rick,
>
> I hope you don't mind me writing to you directly.. i've tried to post
> this twice on the forum and it doesn't seem to go through..
>
>
> As i said, I agree so far.
> What i meant more precisely is that "util" is the implementation of the
> stable part of the API.. and it has methods that take the API's object
> as parameters..
>
> let's say:
> servlet API v1:
> com.servlet.Request
> com.servlet.Servlet
> => public void doRequest(Request)
> com.servlet.Context
> => public void setServlet(Servlet)
>
> servlet API v11:
> com.servlet.Request
> com.servlet.Servlet
> => public void doRequest(Request, String param)
> com.servlet.Context
> => public void setServlet(Servlet)
>
> impl v1:
> util.RequestImpl implements Request (v1)
> util.ContextImpl implements Context (v1)
> implem1.ServletImpl implements Servlet (v1)
>
> impl v11:
> implem11.ServletImpl implements Servlet (v11)
>
> Most of the API (here Request and Context) has not changed and neither
> has the implementation. But then at runtime, implv11 will pass a v11
> version of Servlet to the setServlet() method of Context...
>
> (Am i making any sense or am i just confused?!)
> Honestly, the question arose as a theoretical one and we're not blocked
> in a real life issue for now.
> Now after discussion with a colleague, his opinion is that it's simply a
> packaging issue to duplicate the util class files (for RequestImpl and
> ContextImpl) in both implementation bundles without duplicating the
> actual source code... and i tend to agree with him, as I do not see an
> option to totally avoid duplication.
> What do you think?
>
>
> /Arjun
>
>
>
> Richard S. Hall wrote:
>> I don't see any issues here. Just make sure you have your import
>> ranges properly scoped for the packages you need.
>>
>> For example:
>>
>> APIv1: export api;version=1.0
>> APIv11: export api;version=1.1
>> IMPLv1: export util;version=1.0, import api;version[1.0,1.0]
>> IMPLv11: import api;version=[1.1,1.1],util;version=[1.0,1.0]
>> CLIENTv1: import api;version=[1.0,1.0]
>> CLIENTv11: import api;version=[1.1,1.1]
>>
>> -> richard
>>
>> Arjun Panday wrote:
>>> Imagine we have, in the same JVM :
>>> - API 1.0
>>> - API 1.1
>>> - an implementation bundle for the 1.0 version of the API
>>> - an implementation bundle for the 1.1 version of the API
>>> - a client imports API;version="1.0"
>>> - a client imports API;version="1.1"
>>>
>>> API 1.1 is NOT backward compatible with 1.0 (same classes but
>>> differences in methods signatures)
>>> In spite of the differences, both implementations share the same
>>> code base (based on v1.0); that is, implementation 1.1 extends
>>> (imports) common code from implementation 1.0
>>> (we could move the common code to a separate bundle, but the problem
>>> remains)
>>>
>>> The question is how do we avoid linkage errors? (and avoid
>>> duplicating the common code!) :
>>> the common code and 1.0 implementation are wired to API 1.0, but the
>>> 1.1 implementation will be wired to the 1.1 API AND to the 1.0 API
>>> (for the common code)
>>>
>>> Any suggestion?
>>>
>>> Thanks,
>>> /Arjun
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: the case of not backward compatible API
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I don't see any issues here. Just make sure you have your import ranges
properly scoped for the packages you need.
For example:
APIv1: export api;version=1.0
APIv11: export api;version=1.1
IMPLv1: export util;version=1.0, import api;version[1.0,1.0]
IMPLv11: import api;version=[1.1,1.1],util;version=[1.0,1.0]
CLIENTv1: import api;version=[1.0,1.0]
CLIENTv11: import api;version=[1.1,1.1]
-> richard
Arjun Panday wrote:
> Imagine we have, in the same JVM :
> - API 1.0
> - API 1.1
> - an implementation bundle for the 1.0 version of the API
> - an implementation bundle for the 1.1 version of the API
> - a client imports API;version="1.0"
> - a client imports API;version="1.1"
>
> API 1.1 is NOT backward compatible with 1.0 (same classes but
> differences in methods signatures)
> In spite of the differences, both implementations share the same code
> base (based on v1.0); that is, implementation 1.1 extends (imports)
> common code from implementation 1.0
> (we could move the common code to a separate bundle, but the problem
> remains)
>
> The question is how do we avoid linkage errors? (and avoid duplicating
> the common code!) :
> the common code and 1.0 implementation are wired to API 1.0, but the
> 1.1 implementation will be wired to the 1.1 API AND to the 1.0 API
> (for the common code)
>
> Any suggestion?
>
> Thanks,
> /Arjun
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org