struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <...@fdar.com>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Fri, 25 Apr 2008 15:57:31 GMT
Is this the case, or was the thinking more like:

                                      - app 1
                 - api 1.0 --{
                /                     - app 2
Struts ---{
                \                     - app 4
                 - api 2.0 --{
                                      - app 3

I think this is how I perceived it.  I also agree with Brian that there 
will be a burden on s2 to provide the necessary features for all APIs, 
but I think it's less of a burden in this layout.

/Ian


Brian Pontarelli wrote:
> Here's a few things I think about when considering API versioning:
>
> 1. How many implementors are there? It sounds like there will be one - 
> Struts2
> 2. Do you want to allow implementors to implement multiple APIs? 
> Sounds like yes.
> 3. How much is shared between APIs? Probably a lot.
>
> From what it sounds like, and correct me if I'm wrong, you are looking 
> to do something like this:
>
> API 1.0----------\
>                 |----------- Struts2
> API 2.0----------/
>
> If this is the case, it will require some interesting coding tactics. 
> Sun and IBM have some white papers on these types of cases. OSGi will 
> shield the two APIs from each other so there aren't any conflicts, 
> however, the implementor will have the unfortunate task of 
> implementing both. This becomes difficult without proper structure at 
> compile time because struts2 will need to implement multiple 
> interfaces from both versions and these interfaces might overlap.
>
> I've done some of this type of work before and in order to truly break 
> compatibility between 1.0 and 2.0, you need namespaces in order to 
> allow Struts2 to implement both. Otherwise you get naming conflicts 
> that cannot be resolved by the compiler. I've do things like this before:
>
> org.apache.struts.api1.SomeInterface
> org.apache.struts.api2.SomeInterface
>
> This is the same interface, but breaks compatibility between the API 
> versions. Only by separating the namespaces will you be able to 
> implement both at compile time. I've also worked with other situations 
> like this:
>
> org.apache.struts.api.SomeInterface_1_0
> org.apache.struts.api.SomeInterface_2_0
>
> What it comes down to is that if you are going to break compatibility 
> at the API level you need to actually create a brand new API. When you 
> look at it from this perspective, OSGi really isn't needed, just nice 
> to have. Since the two API versions are in different namespaces, there 
> aren't any collisions at compile-time or runtime, eliminating the need 
> for bundle separation.
>
> Having done some of these types of solutions before, I can attest to 
> the pain that they can cause. They can also become complex to manage. 
> Which sorta leads back to my original statements about compatibility. 
> I'd much rather see something like this:
>
> 1. The APIs locked down
> 2. These APIs called Struts3
> 3. No APIs break compatibility until Struts4
>
> Therefore, 3.0, 3.1, 3.2, etc are all compatible. Then when Struts4 
> start wanting to break compatibility, you branch Struts3, and start 
> breaking away on Trunk.
>
> -bp
>
>
>
> Don Brown wrote:
>> As I learn more and more about OSGi, I wonder if it might be the
>> solution to several big problems we seem to have at the moment: poor
>> reloadability and the lack of a solid API.  With OSGi, you can drop
>> bundles in and out of the system at runtime, even running multiple
>> versions of the same bundle side-by-side, but the feature I'm most
>> interested in right now is how it would allow us to put in a proper
>> API while maintaining full backwards-compatibility.
>>
>> Evolving a web framework is hard because apps tend to be written on a
>> specific version, and to migrate them to new versions has two
>> problems: development may not be continuously funded and the upgrade
>> may require too many changes to the application.  On the other hand,
>> if you don't evolve your web framework, you quickly go out-of-date and
>> lose interest from new developers.  In our case, despite being a
>> relatively new framework, we have legacy code around from 2004 that we
>> can't just remove, yet we want to provide an attractive, modern, clean
>> framework for new development.
>>
>> The specific issue it hand that I've been thinking about is how to get
>> a proper API into Struts 2 yet keep backwards compatibility, and I
>> think OSGi might provide a solution.  What about this:
>>  1. Struts 2 and its plugins remain the way they are now - 100%
>> backwards-compatibility
>>  2. An OSGi plugin provides the platform for the next generation of 
>> Struts 2
>>  3. A new API bundle is created, implemented by the underlying Struts
>> 2 framework
>>  4. Old apps can continue to write and deploy code against Struts 2,
>> yet new development can start to use the new API
>>  5. Later, when we want to write API version 2, we create a new bundle
>> that runs side-by-side the old bundle, both implemented by Struts 2
>>
>> Basically, OSGi would allow us to write a clean layer on top of a
>> framework, much like how Grails builds on Spring, but we get, as a
>> side benefit, all the architectural advantages of OSGi for free.
>> Furthermore, if we do it right, users don't have to know or care that
>> OSGi is under the hood - all they know is they write a jar, drop it in
>> a directory or upload it via a form and they just installed part of
>> their application at runtime.
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message