Don,
I just tried the all.zip bundle and I see that some of the new plugins
are missing:
struts2-dojo-plugin-2.1.1.jar
struts2-dwr-plugin-2.1.1.jar
struts2-junit-plugin-2.1.1.jar
struts2-spring-plugin-2.1.1.jar
struts2-testng-plugin-2.1.1.jar
I added the missing jars to the assembly config
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'd like to work on some of the Strut 2 docs. I've got my CLA turned in
and I'm listed on the ASF committers page as Matthieu Chase Heimer. My
Confluence account name is my email address, [EMAIL PROTECTED]
Thanks,
Chase
-
To
Done.
--
Martin Cooper
On Fri, Apr 25, 2008 at 4:19 PM, Chase [EMAIL PROTECTED] wrote:
I'd like to work on some of the Strut 2 docs. I've got my CLA turned in
and I'm listed on the ASF committers page as Matthieu Chase Heimer. My
Confluence account name is my email address, [EMAIL
Could you do what you propose with a custom interceptor stack? Make your
first call to getModel() return a serialized copy of the model object
and the second call return the managed instance. Internally the action
would maintain the reference to the managed instance from the time of
the first
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
Eric D Nielsen wrote:
I've been investigating some interesting behavior regarding model-driven actions
and found a past thread that covers the situation from late last year:
http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html
...
It would seem to be
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
14 matches
Mail list logo
