Jeromy Evans wrote:
Putting aside the technology for a moment:
- ability to deploy new actions/replace actions and pages without a container restart: highly desirable
Only at development stage right? There are tools that use JDPA and other methods to do this with Struts and other frameworks. However, Groovy is probably the best way to go moving forward for this type of handling if you want more language features. OSGi will help with this as well since it can reload bundles. Just have to ensure that whatever you are using works in conjunction with all the other frameworks you've got in the application, like Spring/Guice. Some tools will do this without changes to Struts while others (OSGi from what I know about it) will require changes to Struts or implementation of APIs like ObjectFactory.

- ability to deploy new/replace business-layer services without a container restart: highly desirable
Same tools as above will help in this department, including OSGi. The trick again is injection and other frameworks. Spring and Guice have good adoption in most tools and will work well.

- ability to evolve Struts2 without fear of breaking an API; highly desirable
Developers need to do this. The API needs to be frozen and then the implementation can change without fear of breaking applications and plugins. To date this has not occurred and from my perspective nothing but good programming will solve this one.

-bp




If, through appropriate packaging, OSGi facilities those requirements that them I'm all for it. At this point I don't have a good appreciation of what *actually exists* in this area.

I'd take care to ensure Struts2 continues to target entry-level containers though (ie. Tomcat rather than Glassfish).

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to