Dollin [mailto:[EMAIL PROTECTED]
Sent: Sun 12/21/2003 12:50 AM
To: 'Struts Developers List'
Cc:
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
There is another benefit to the way that struts does things. Since
Don Brown wrote:
Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is. Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine
Yes, it is possible to do a lot of things with Struts currently, but for
the most part, they are all hacks. With Struts 2.0, we have a chance to
look at Struts best practices, other web frameworks, and current
technologies to design Struts to be the best and easiest framework for
web
Don Brown wrote:
With Struts 2.0, we have a chance to
look at Struts best practices, other web frameworks, and current
technologies to design Struts to be the best and easiest framework for
web applications, and perhaps beyond.
I hope it's more of a revolution than evolution, it be more fun, look
Hack might be too strong a word. I'd call it a reasonable alternative
extension of the framework :)
If we want to look at the WebWork/Maverick approach of using a single
input/command handler, where Struts has separate input and command
handlers, why not add the said standard ExecuteFormAction
I think that sounds like a good compromise. In my view, there are really
two types of forms - small ones with one or two parameters, and full
blown complex input forms. In the former case, I think combining the form
and action is a good idea; the latter, probably not so much.
In WebWork2/XWork,
Quoting [EMAIL PROTECTED]:
I think that sounds like a good compromise. In my view, there are really
two types of forms - small ones with one or two parameters, and full
blown complex input forms. In the former case, I think combining the form
and action is a good idea; the latter, probably
To: Struts Developers List
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I think that sounds like a good compromise. In my view,
there are really two types of forms - small ones with one
or two parameters, and full blown complex input forms. In
the former case, I think
I'm not looking to get rid of the ActionForm objects, just automate its creation
based on my DTO for cases where it makes sense.
Today, a lot of my forms do something like this:
1. Caller brings up the page with Form A (let's say an Edit Record form)
2. Action responds by requesting data from
I totally agree - let me clarify. I think Struts 2.0 could use an IoC
framework like Spring to help improve its internal structure. Any
configuration files should be stored in the Struts jar, but be able to be
overridden by specifying an alternate IoC configuration path. This lets
advanced
Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to
allow the form model to be anything from a DOM to a JavaBean or even a
DynaBean. XMLForms came out of Cocoon, but I believe they still use
something simliar. In stxx (http://stxx.sf.net), a Struts extension, I
have been
On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:
snip /
What kind of Spring Framework classes would you want to use in
Struts 2.0?
The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
Craig R. McClanahan wrote:
There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a form bean in the
conceptual sense:
(1) A set of typesafe field names and corersponding values
where the application doesn't
:
[EMAIL PROTECTED]Assunto: Re: Struts 2.0 Ideas (was Re:
Struts 2.0 Discussion Forum)
.com
Don Brown wrote:
I see Spring as helping Struts be better structure its internal
components, specifically using a BeanFactory implementation. It would not
replace struts-config in any way or even be exposed directly the a Struts
application. The struts-chain request processor implementation
Do we still want to integrate stxx into Struts 1.x?
Don Brown wrote:
Using JXPath is exactly what XMLForms (http://www.xmlforms.org) does to
allow the form model to be anything from a DOM to a JavaBean or even a
DynaBean. XMLForms came out of Cocoon, but I believe they still use
something
--- Don Brown [EMAIL PROTECTED] wrote:
On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:
snip /
What kind of Spring Framework classes would you want to use in
Struts 2.0?
The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
==///==
Craig R. McClanahan wrote:
There's a couple of variations on the theme that are
possible, but I can think
of at least three layers of something that might be called
a form bean in
David Graham wrote:
If we want IoC inside of Struts we should look at something lighter weight
like HiveMind. I'd also like some focused concrete examples of how IoC
would benefit Struts internals before we decide to go that route.
I think this is an important point. All we can do here is
At 3:47 PM + 12/19/03, PILGRIM, Peter, FM wrote:
Having spoken with Don Brown, I can see the benefits now
of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating
a graph of objects from an XML file is pretty handy for certain
situations. I can see the light of the joke. Objects just
We have a solution for dynamic page content that is component based. I
wouldnt say that it stands up to JSF but its similar in concept. The
content of the page is defined using xml metadata.
However, I suppose that you could argue, why not use JSF? I would be
interested in hearing what
Yes, Spring is nice becuse not only does it provide a consistent
factory-based implementation, but the code isn't dependent on Spring and
could be replaced with some other IoC mechanism down the road if desired.
Don
On Fri, 19 Dec 2003, Ted Husted wrote:
Don Brown wrote:
I see Spring as
What about including a Dynamic rules-based workflow engine? One like Drools?
This is great because it abstracts a lot of the operational control of the
application into the realm of the business person. It seems to me that IoC is a
good start, but following up with a business rules based control
Quoting [EMAIL PROTECTED]:
We have a solution for dynamic page content that is component based. I
wouldnt say that it stands up to JSF but its similar in concept. The
content of the page is defined using xml metadata.
However, I suppose that you could argue, why not use JSF? I would be
Quoting n. alex rupp [EMAIL PROTECTED]:
What about including a Dynamic rules-based workflow engine? One like
Drools?
This is great because it abstracts a lot of the operational control of the
application into the realm of the business person. It seems to me that IoC
is a
good start, but
Hi Craig,
A completely different way to consider using JSF would be to build a RenderKit
that took input like this and generated the corresponding HTML (or whatever)
markup, starting from the exact same components as the standard HTML RenderKit.
In the JSF release, there is the very beginnings
If we do things right, IMHO workflow support system(s) should be a layer on top
of the foundational request handling capability, so you can use it if you need
it but it doesn't get in the way if you don't.
I think I agree here. Isn't workflow something that the business tier implements in a
Quoting Mete Kural [EMAIL PROTECTED]:
Hi Craig,
A completely different way to consider using JSF would be to build a
RenderKit
that took input like this and generated the corresponding HTML (or
whatever)
markup, starting from the exact same components as the standard HTML
RenderKit.
In
Quoting Mete Kural [EMAIL PROTECTED]:
If we do things right, IMHO workflow support system(s) should be a layer on
top
of the foundational request handling capability, so you can use it if you
need
it but it doesn't get in the way if you don't.
I think I agree here. Isn't workflow
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 11:00 AM
To: Struts Developers List
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting [EMAIL PROTECTED]:
We have a solution for dynamic page content
Craig R. McClanahan wrote:
Workflow is one of those wonderful words that means different things to
different people :-). It makes sense to think about webapp frameworks wanting
to deal with workflows for individual conversations (think of managing a wizard
dialog, which is a very common use case)
Quoting [EMAIL PROTECTED]:
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 11:00 AM
To: Struts Developers List
Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting [EMAIL PROTECTED]:
We have
David Graham wrote:
--- Don Brown [EMAIL PROTECTED] wrote:
On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:
snip /
What kind of Spring Framework classes would you want to use in
Struts 2.0?
The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is
David Graham wrote:
--- Vic Cekvenich [EMAIL PROTECTED] wrote:
And even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in
-Original Message-
From: Sgarlata Matt [mailto:[EMAIL PROTECTED]
Sent: 17 December 2003 22:11
To: Struts Developers List
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers
David Graham wrote:
--- Vic Cekvenich [EMAIL PROTECTED] wrote:
And even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: 17 December 2003 23:00
To: Struts Developers List
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
====
A sort of meta-question: When is Struts no longer Struts? I
mean, how much
The BeanWrapper and the BeanFactory are interesting ideas.
An example of configuring commons DBCP is given
http://www.springframework.org/docs/lightweight_container.html
I am not convince however of the requirement for BeanFactory.
I can understand if you need to have massive XML configuration
In terms of new functionality, the three biggest fish I'd like to fry
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to
consider integrating LivingLogic's Workflow, ssl-ext, and Struts
TestCase into the Struts 2.x development stream. We may also want to
consider adding these
public ActionForward someStateAction(
org.apache.commons.chain.Context context );
It can *all* go into context(or a Map!!!), else we have the tilesAction
execute signature.
I can allways do a
map.get(request)
This would work for SOAP or other protocols.
I was going to add:
This lets
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
In terms of new functionality, the three biggest fish I'd
like to fry
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to
consider integrating LivingLogic's Workflow, ssl-ext, and
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
====
public ActionForward someStateAction(
org.apache.commons.chain.Context context );
It can *all* go into context(or a Map!!!), else we have the
tilesAction
execute signature.
public ActionForward someStateAction(
org.apache.commons.chain.Context context,
some.generic.request request,
some.generic.response response );
Why not just KISS and
public ActionForward someStateAction(
org.apache.commons.chain.Context context );
It can *all* go into context(or a
PILGRIM, Peter, FM wrote:
This is early days, and too-low level so I 'd put this point
on the back burner.
We've started to track suggestions like these here:
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-jericho/
to help avoid recovering the same ground.
Of course, what's on
On Wed, 17 Dec 2003, Don Brown wrote:
Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
release work. :) I'll throw out some ideas here, then develop them later
in the wiki:
- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes
Quoting Martin Cooper [EMAIL PROTECTED]:
Just to add a few more off the top of my head:
* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.
* Separate view-technology-specific code into separate components, so that
the
Craig R. McClanahan wrote:
Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).
JDK 1.4,
On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
Quoting Martin Cooper [EMAIL PROTECTED]:
Just to add a few more off the top of my head:
* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.
* Separate
Quoting PILGRIM, Peter, FM [EMAIL PROTECTED]:
[snip]
Although it's not evident from the Jericho DTD, the intention
is to use
a Context object in the signatures, perhaps the Commons Chain
Context,
so as to encapsulate Servlet/Portlet dependencies.
So you no longer going to
Martin Cooper wrote:
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. There is a boatload of frameworks out there
now, and some of them have some great ideas. What I don't really want to
end up with is a Struts 2.0 that is simply a reinvention of
Quoting Vic Cekvenich [EMAIL PROTECTED]:
Craig R. McClanahan wrote:
Regarding 2.x, an important consideration will be base technology platforms
--
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
(i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using
I don't think I'm going to articulate this question very clearly, but
hopefully my drift will be gotten, so to speak.
If we're talking about making Struts independent of Servlets, then
what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?
Rather, how will we partition Struts
Martin Cooper wrote:
I think I need to elaborate on my thoughts some more, since I wasn't
really clear the first time around...
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago.
new technologies:
bytecode manipulation
IoC
SOA
filters
xml (XML
Quoting Joe Germuska [EMAIL PROTECTED]:
I don't think I'm going to articulate this question very clearly, but
hopefully my drift will be gotten, so to speak.
If we're talking about making Struts independent of Servlets, then
what part of Struts would depend on either Servlet 2.3 or
Quoting Martin Cooper [EMAIL PROTECTED]:
On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
Quoting Vic Cekvenich [EMAIL PROTECTED]:
Craig R. McClanahan wrote:
Regarding 2.x, an important consideration will be base technology
platforms
--
I'm in favor of using J2SE 1.4 and
Craig R. McClanahan wrote:
One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on. You can do exactly the same thing with
Filters by making each
I am thinking of fliping sides on FormBean as interface, I am now
leaning against formbeans being an interface. FormBean is a concept
(properties that map to form elements), plus this idea of XML as a
FormBean. It could be a List or String or anything.
XML as a FormBean! That got my
--- Mete Kural [EMAIL PROTECTED] wrote:
FormBean is a concept
(properties that map to form elements), plus this idea of XML as a
FormBean. It could be a List or String or anything.
XML as a FormBean! That got my attention...
What I would like to explore is the possibility of reusing
For a given form/action, the framework will be supplied with the FQCN of the
DTO/VO. From there, it can determine what the fields of the form will be. The
form bean validation/descriptor XML will provide the validation information and
any conversion rules as needed to format/parse between the
I think we're tackling different issues here.
What I'm trying to avaoid is having (1) a data transfer object used by the
different tiers, and (2) a form bean object or dyna form bean definition which is
a close reflection of the fields that the DTO already defines, and (3) a
validation rule xml
The documentation's a bit sketchy, but the FormProc project in
SourceForge works this way. The idea is that it validates and populates
another object directly from the request parameters. At some point, I'd
like to try to make it an alternative to the Commons/Struts Validator.
But this would
The dynamic field use case comes up all the time, but I have trouble
getting my head around it. What would be helpful would be a example
application that people could play with. You can take thought
experiments only so far :)
My first question would be how would anything (never mind Struts)
Ted Husted wrote:
The dynamic field use case comes up all the time, but I have trouble
getting my head around it. What would be helpful would be a example
application that people could play with.
And making it that dynamic defeats testing and layers.
I am not aware of even Client Server uses
List
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
The dynamic field use case comes up all the time, but I have trouble
getting my head around it. What would be helpful would be a example
application that people could play with. You can take thought
experiments only
The dynamic field use case comes up all the time, but I have trouble
getting my head around it. What would be helpful would be a example
application that people could play with. You can take thought
experiments only so far :)
Yeah you're right. There needs to be an example application. We have
Quoting Vic Cekvenich [EMAIL PROTECTED]:
Craig R. McClanahan wrote:
One of the things people have said they liked about using a chain to
decompose
RequestProcessor is that you could easily compose your own chains, adding
your
own custom processing stages and so on. You can do
Craig R. McClanahan wrote:
For all three of the cases, though, we
probably want to invent a different term than form bean because that seems so
conceptually tied to presentation only. Transaction Bean? Input Bean? Data
Transfer Object :-)?
InputHandler?
-T.
Quoting Mete Kural [EMAIL PROTECTED]:
I am thinking of fliping sides on FormBean as interface, I am now
leaning against formbeans being an interface. FormBean is a concept
(properties that map to form elements), plus this idea of XML as a
FormBean. It could be a List or String or anything.
Quoting Ted Husted [EMAIL PROTECTED]:
Craig R. McClanahan wrote:
For all three of the cases, though, we
probably want to invent a different term than form bean because that
seems so
conceptually tied to presentation only. Transaction Bean? Input Bean?
Data
Transfer Object :-)?
Craig R. McClanahan wrote:
Quoting Ted Husted [EMAIL PROTECTED]:
InputHandler?
That would certainly be an appropriate name for my type (3) form bean (that
included event handling), and perhaps even for a type (2) form bean that
includes some sort of hooks into validation. It doesn't fit the type
The gotcha is that a DTO usually has typed fields, and can't redisplay
invalid data. An ActionForm is specifically designed to capture String
input, validate it, then redisplay it if necessary, so it can then be
converted to whatever type is desired. Most DTO's aren't up for this
type of
That's exactly what I meant to say, of course I just didn't articulate it as well
as you did. =) Form bean details are spread all around, violating the DRY
principle. The DTO's can be used to tell Struts how to generate dynamic action
forms that it (and the validator) can work with, without the
Quoting Hubert Rabago [EMAIL PROTECTED]:
That's exactly what I meant to say, of course I just didn't articulate it as
well
as you did. =) Form bean details are spread all around, violating the DRY
principle. The DTO's can be used to tell Struts how to generate dynamic
action
forms that it
Is there one? I have several ideas I'd like to toss into the discussion.
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard
On Wed, 17 Dec 2003, Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the discussion.
I'm +1 for keeping it here on the dev list. (if that's what you meant)
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added:
Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the
discussion.
Don
There's a Whiteboard page in the Wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
I'll be posting more about Jericho, but wanted to get what I had so far
(a starter DTD) under
What about allowing Action objects to add the parameters themselves? It adds a
great deal of flexibility, and doesn't limit the set of parameters that can be
used, nor does it require using the request or session attributes.
ActionForward forward = mapping.findForward(lookup);
On Wed, 17 Dec 2003, Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the discussion.
Yep. This is it.
--
Martin Cooper
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho README.txt
- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (100k), really easy to use, and easily
extendable. If
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 5:04 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
So then, with specific frameworks, I don't understand how Pico's
And you're really going to have to break both of my arms and/or kick me
out of Struts development if you want ActionForm *ever* changed to an
interface again -- in *any* future Struts release. I think it's an
absolutely horrible idea, for reasons that have been documented way too
many times
Are we on something revolutionary here? I am looking forward to this.
BaTien
DBGROUPS
Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the discussion.
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho
On Wed, 17 Dec 2003, Joe Germuska wrote:
- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (100k),
Just to add a few more off the top of my head:
* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.
* Separate view-technology-specific code into separate components, so that
the core is view-technology agnostic. So, for
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
So then, with specific frameworks, I don't understand how Pico's
orientation towards constructors works in an environment where beans
need to be dynamically instantiated, but perhaps I just haven't
thought about it hard
PROTECTED]
Sent: Wednesday, December 17, 2003 5:20 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Nope, Spring is Apache-style, I just checked. You had me worried there
for a minute :)
Don
On Wed, 17 Dec 2003, Sgarlata Matt wrote:
- Original Message -
From
Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is. Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
I think this might be a that was then, this is now issue. Once upon a
time, people were trying to do nutty things like use Entity Beans for
ActionForms. But people are older and wiser now, and more importantly,
we have DynaActionForms and tools like XDoclet to mitigate the
maintenance issues.
Martin Cooper wrote:
* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config
(was: Struts 2.0 Discussion Forum)
What about allowing Action objects to add the parameters themselves? It
adds a
great deal of flexibility, and doesn't limit the set of parameters that
can be
used, nor does it require using the request or session attributes.
ActionForward forward
Martin Cooper wrote:
* Make the Struts core independent of the Servlets spec SNIP
Above is my favorite wish!
I would like to be able to call an Action via XML-RPC for it to give me
a FormBean and for me to give it a FormBean back. (or any other
SOA). There was a few threads of SOAP
- Also, again totally agreeing with Ted, make everything interface
based,
a few more hears here ;^)
Joe Germuska
The interface discussion has come up previously and there was some emotion
tied to it.
I was around for Interface ActionForms in pre Struts 0.5 and it was
Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 09:22 PM
To: 'Struts Developers List'
Subject: Re: Struts 2.0 Discussion Forum
Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the
discussion.
Don
There's
--- Vic Cekvenich [EMAIL PROTECTED] wrote:
And even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in Struts.
[EMAIL PROTECTED] wrote:
I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.
I believe the plan was to do both. Work can continue on Struts 1.x.x to
evolve it
95 matches
Mail list logo
