How does this affect XWork? It seems like most of this would need to be
integrated into XWork core, so, would XW need to be completely overhauled?
Move it to the ASF?
Or do we drop XW altogether for something else?
Is there enough here with this proposal for an Action Framework JSR?
On Sun,
Nope, no changes to XWork are necessary, and most likely no changes to
Struts 2 core either.
Don
On Mon, Apr 28, 2008 at 11:46 PM, James Mitchell [EMAIL PROTECTED] wrote:
How does this affect XWork? It seems like most of this would need to be
integrated into XWork core, so, would XW need to
Ok, I promised a more detailed proposal, so here it is:
http://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi
I converted Jeromy's goals into a more proper tech spec (with the
pretty diagrams to follow...)
I highly recommend those not familiar with OSGi to take a look at
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.
Don Brown wrote:
I'll respond in more detail later, but I wanted to correct a quick
misconception. OSGi allows you to deploy multiple versions of the
same API via different bundles. No special package namespace, no
hassles from the standpoint of the user - just declare what version
you need
Since I started playing with the OSGi plugin this has been on the back
of my mind, I think it would be a good idea (support for OSGi is
showing up all over the place,
There will be another player:
JSR 277 is intended to be part of Java 7. Someone commented on a blog that JSR
277 will have
Don, this sounds like a really good idea.
I currently have the problem to upgrade several apps from different S2/WW
versions to the latest release and your suggestion sounds like an ideal
way to do such migrations.
I'm curious about your plans and would like to hear more details.
Maybe we should
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
Is this the case, or was the thinking more like:
- app 1
- api 1.0 --{
/ - app 2
Struts ---{
\ - app 4
- api 2.0 --{
-
Yours and mine are the same because you still have implementations
inside Struts for some of the API interfaces. For example,
org.apache.struts2.config.PackageProvider (yeah, I did move this from
XWork to Struts for my example ;), will be an API interface that
applications can implement.
Maybe I'm overstepping my knowledge from fact, but I thought the benefit
of OSGi was that you could have completely different implementations
(i.e. PackageConfig) running on the same JVM, with OSGi providing the
classloading magic so that the implementations don't collide.
If this is the
Ian Roughley wrote:
Maybe I'm overstepping my knowledge from fact, but I thought the
benefit of OSGi was that you could have completely different
implementations (i.e. PackageConfig) running on the same JVM, with
OSGi providing the classloading magic so that the implementations
don't
I'll respond in more detail later, but I wanted to correct a quick
misconception. OSGi allows you to deploy multiple versions of the
same API via different bundles. No special package namespace, no
hassles from the standpoint of the user - just declare what version
you need and it all just
Putting aside the technology for a moment:
- ability to deploy new actions/replace actions and pages without a
container restart: highly desirable
- ability to deploy new/replace business-layer services without a
container restart: highly desirable
- ability to evolve Struts2 without fear of
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
I like your thinking and I'm curious to hear more. Are you referring
to something like the OSGi Plugin for loading plugins, or are you
saying that you want to make Struts 3 only run in an OSGi container?
Matt
On Thu, Apr 24, 2008 at 9:09 AM, Don Brown [EMAIL PROTECTED] wrote:
As I learn more
I'm also pretty stoked about the possibilities of OSGi; I think it's a
potentially Pretty Big Win for all sorts of functionality. I don't know a
whole lot about OSGi yet, but it sure seems like a globally-useful tool.
I'm all for it; +1.
Dave
--- Don Brown [EMAIL PROTECTED] wrote:
As I learn
Since I started playing with the OSGi plugin this has been on the back
of my mind, I think it would be a good idea (support for OSGi is
showing up all over the place, I just read somewhere that glassfish
will run on an OSGi platform)
musachy
On Thu, Apr 24, 2008 at 12:09 PM, Don Brown [EMAIL
18 matches
Mail list logo
