struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Fri, 25 Apr 2008 15:22:06 GMT
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


Mime
View raw message