On 5/3/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
We need to release version 2 of the struts-parent pom:
* http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml
RESULT
+1 - 6 (binding)
I'm publishing it now...
Thanks,
Wendy
--
Our JIRA instance is showing a stack trace on the dashboard.
I opened a ticket for it: http://issues.apache.org/jira/browse/INFRA-789
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/WhyChain
The comment on the change is:
Added some pictures (will need to refactor the chain docs)
I am a struts user who has recently began programming in webwork, to get
a head start for action 2. Having just spent many hours researching,
reading about and experimenting with webwork, I personally hope that you
start with a version of action 2 that resembles webwork pretty closely.
I wonder ho
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
The current versioning/naming system will force them, because it does
not make distinction between Classic and WebWork. Most users and/or
their managers know that higher version number means newer and better
product. Which is why I preferred
If you looked at the Struts Ti proposal, you'd see that the goal was to start
developing advanced features to dramatically simplify development. The whole
reason we looked at WebWork in the first place is we wanted a solid foundation
so that we could focus on features.
With the merger comes a
Ted, I think that your statement is one of the things that needs to be
discussed. There is the camp that says "The first SAF 2.0 release should have
a solid API that will be usable for a long time". The second group says that
"The first SAF 2.0 release should basically be WW 2.2 with some mino
On 5/5/06, Phil Zoio <[EMAIL PROTECTED]> wrote:
Michael Jouravlev wrote:
> On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
>> If the existing branches can continue to develop, then the community
>> is not
>> hurt by breaking compatibility, they are actually HELPED because the
>> me
Michael Jouravlev wrote:
On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
If the existing branches can continue to develop, then the community
is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will
On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
If the existing branches can continue to develop, then the community is not
hurt by breaking compatibility, they are actually HELPED because the
merger yields a much greater value in the end, and people will probably
want to migrate despit
On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
But that's precisely my point... isn't the best way to combine the
talents to "take the cuffs off", so to speak, and not worry about
backwards-compatibility?
Yes, and this is why the Ti proposal talks about two phases.
In the first phase,
This sounds fine to me, Don.
I'd suggest annexing this to the original Ti proposal as a clarification.
-Ted.
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
What's the goal of SAF 2.0?
<
1) Clean up some of the more annoying points of WebWork and XWork but generally
have a backward compatible framework that WebWork users can easily jump on to
quickly
+1
SAF 2.0 == WW 2.3
I'm still working off
Joe Germuska wrote:
What about a String constant representing a global warning, and then only
warn(String fieldName, String key)
warn(String fieldName, String key, Object...)
i.e.
warn(GLOBAL, "warnings.foo", 42);
Hmm...I'm not generally a fan of constants when a separate method would do, but
Gabe wrote:
I am all for simplifying the API to the end developer, but I wonder if those
changes could be pushed to XWork in the form of an XWork 2.0, with, of course,
the Web specific portions being added to SAF 2.
Agreed, and with my XWork developer hat on, XWork 2.0 will be required to
sup
I am all for simplifying the API to the end developer, but I wonder if those
changes could be pushed to XWork in the form of an XWork 2.0, with, of course,
the Web specific portions being added to SAF 2. I see the reasoning behind
creating a layer to hide XWork (everything the user uses is Stru
Don Brown wrote:
The purpose of this merger is not to create yet another framework or
kill off competition, but to start collaborating as framework developers
for the greater good of the general community. By focusing on who can
do what or why can't a project release something, you are missing
My company, Autoriginate (http://www.autoriginate.com), has donated a free
HostedQA account to all Struts developers who request one. The account is
available at https://struts.hostedqa.com. Just speak up if you want an account
and I'll set you up.
So what does this get us? I've already checked
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
--
- Describe Shale
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
--
+ Vario
Gabe wrote:
Where XWork is in this proposal is a little vague. Would this proposal break
the traditional division of roles between XWork and Webwork (Where SAF 2 is
where webwork was)? If so, how so? Is this proposing that there be an adapter
layer in SAF 2 to access XWork APIs? Would we be look
If the WebWork committers make the decision to continue developing WebWork 2.x,
they are entirely free to do so. If Struts Action 1 committers decide to
continue developing Action 1, they are also free to do so. However, if WebWork
2 developers decide to stop work and focus completely on Strut
Don,
Thanks for drawing up a proposal. I suggest allow ample discussion time before
this is called to a vote.
Where XWork is in this proposal is a little vague. Would this proposal break
the traditional division of roles between XWork and Webwork (Where SAF 2 is
where webwork was)? If so, how
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/DebuggingShaleClay
New page:
== Incorrect public id ==
=== Problem ===
When running a web application
I'm OK with this, from an end user perspective certainly, and from a
(sort of I guess) framework developer as well.
However, you raise an interesting point in my mind...
"Struts Action 1.x will continue to be developed actively"
Ok... I personally like that. However, why wouldn't it also be s
Just as some people continue to use WebWork 1.xx (JIRA) I imagine
people will continue to use SAF1 regardless of how easy the migration
path is.
I always assume it would take a day or two to convert existing WW code
to SAF2 so at the end of the day just picking a direction is progress.
:)
Cheers
Michael Jouravlev wrote:
SAF1 could have future if migration to SAF2 were impossible or too
complicated. But according to your plan, migration from SAF1 to SAF2
should take days. What is the point of keeping Action 1.x "to be
developed actively"?
I am not objecting, I am just asking. Trying to
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
The comment on the change is:
Adding Debugging Tips
--
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2. Backwards-
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by RyanKanno:
http://wiki.apache.org/struts/ShaleClay
New page:
Describe ShaleClay here.
---
Ok, let's just make this an official proposal and focus all of this discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2. Backwards-compatibility support for WebWork 2 and Struts 1.x
Cool :) That jives with what has been said in the past, I just wanted,
as a current SAF1 user, to make sure that message didn't get lost.
Frank
Jason Carreira wrote:
Right, this is very important, but it's always been planned that there would be
a migration kit + some effort to migrate an ex
--- Jason Carreira <[EMAIL PROTECTED]>
wrote:
> It was always assumed until recently that WebWork
> users would find it very simple to move to SAF 2.x
> and would quickly form a community around SAF 2.0.
> If the API is going to be very different, the
> migration path for WebWork users is going
What about a String constant representing a global warning, and then only
warn(String fieldName, String key)
warn(String fieldName, String key, Object...)
i.e.
warn(GLOBAL, "warnings.foo", 42);
Joe
At 12:26 PM -0700 5/5/06, Bob Lee wrote:
There's some potential overloading ambiguity. For exam
To err is human... do not lightly give this power to web applications ;-)
> I'm cool with that. Sticking with verbs, there's also
> err(), warn(),
> inform(). ;)
>
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jsp
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/Shale/UserDocs
The comment on the change is:
Added a link for Clay
Right, this is very important, but it's always been planned that there would be
a migration kit + some effort to migrate an existing Struts 1.x app to SAF 2.0,
but we've always planned for that.
It was always assumed until recently that WebWork users would find it very
simple to move to SAF 2.x
On 5/5/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Although you don't mention it here, I think it's always been kind of
implied... still, I'd like to see it explicitly stated, and that is,
what about existing Struts users? Will they have a migration path (and
what is it?), or not? The same
On May 5, 2006, at 12:47 PM, Craig McClanahan wrote:
Consider the way the world was before JSR-168 happened ... every
portal
server had their own completely different API for building portlets
Yes, and I am stuck working on one of those (or should I say working
*around* one of those) as w
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier
(to me).
I can see how verbs make the code easier to *read*, but not sharing a common
prefi
Although you don't mention it here, I think it's always been kind of
implied... still, I'd like to see it explicitly stated, and that is,
what about existing Struts users? Will they have a migration path (and
what is it?), or not? The same kind of question your asking for Webwork
users in oth
I'm cool with that. Sticking with verbs, there's also err(), warn(),
inform(). ;)
Bob
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier (to
m
There's some potential overloading ambiguity. For example:
void warn(String key, Object... arguments);
void warn(String fieldName, String key);
Right now, if I want to add a global warning with one String argument,
I'll have to cast the argument to Object:
messages.warn("key", (Object)
So we've gone off on many tangents, but the core question remains unanswered.
What's the goal of SAF 2.0?
Are we looking to:
1) Clean up some of the more annoying points of WebWork and XWork but generally
have a backward compatible framework that WebWork users can easily jump on to
quickly
2
Yeah, I generally like it, but I still prefer the more obvious addError(),
addWarning(). I like my methods as verbs... makes reading the code easier (to
me).
> - The attached version supports arbitrary levels. I
> used an interface
> instead of an enum so the user can define additional
> levels
On May 5, 2006, at 9:36 AM, Jason Carreira wrote:
Ugh... I really don't like that... really... seems like using an
ugly hack instead of defining a higher-level abstraction.
The deal breaker for me was that users will be able
to reuse the same
code inside and outside of our framework. They
Addresses my concerns quite nicely and should be easy to refactor code against.
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
> - The attached version supports arbitrary levels. I used an interface
> inste
I like it, Level should extend Comparable, and Global works for me.
Don
Bob Lee wrote:
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish. Should Level extend Comparable?
- It has built in support for I
On 5/5/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> Therefore, I personally consider JSR-168 a big mistake, and I would
> prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had
On 5/5/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> I would think we'd want to support some explicit
> notion of a "setup" phase
> right before rendering, and a "cleanup" phase
> afterwards. That way, you can
> do things like open a Hibernate session and do a
> query that's needed to
> popul
- The attached version supports arbitrary levels. I used an interface
instead of an enum so the user can define additional levels if they
wish. Should Level extend Comparable?
- It has built in support for INFO, WARN, and ERROR along with
respective convenience methods.
- It provides a Map of fi
Craig McClanahan wrote:
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Therefore, I personally consider JSR-168 a big mistake, and I would
prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had their own completely different A
> I would think we'd want to support some explicit
> notion of a "setup" phase
> right before rendering, and a "cleanup" phase
> afterwards. That way, you can
> do things like open a Hibernate session and do a
> query that's needed to
> populate a table, then clean up the session
> afterwards. (J
On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Therefore, I personally consider JSR-168 a big mistake, and I would
prefer it to die peacefully.
Consider the way the world was before JSR-168 happened ... every portal
server had their own completely different API for building portlets,
>
> If support for a portlet environment is a goal for
> SAF2, remember that there
> is more to it than just papering over the differences
> between the portlet
> and servlet APIs. You also have to deal at the
> functional level with the
> differences in the request processing lifecycle of
> the
>From the discussion there, it looks like they already had something mimicking
>the HttpServletRequest with a lot of the same methods copied over and were
>pretty tightly coupled already to the environment they were in. The WebWork /
>Xwork code is not, so I don't see us as being in the same pos
On 5/5/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
If support for a portlet environment is a goal for SAF2, remember that there
is more to it than just papering over the differences between the portlet
and servlet APIs. You also have to deal at the functional level with the
differences in th
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
These are very good points. How does JSF handle the multiple renders?
For the implementation questions below, my answers are based on the
jsf-portlet bridge code in the RI's java.net project. AFAICT, the
implementations inside MyFaces and the
Struts Action 1.3.2 has received the following votes:
Beta - Don Brown, Wendy Smoak, Martin Cooper, James Mitchell
Alpha - Ted Husted
Therefore, Struts Action 1.3.2 will be designated "Beta" quality. If
I have a chance, I'll sign the releases and make it available on the
web page to prompt more
These are very good points. How does JSF handle the multiple renders? Do you
have to ensure your backing bean is session scoped? Wouldn't a request scope
mean the data would be lost at the end of the processAction()? How would you
expect a portlet lifecycle to be supported with a stateless A
Yeah - you're right - I've been working in declarative validations for
too long
Don Brown wrote:
No, the developers would use .info/warn/error to add messages, but I'm
saying they probably wouldn't need to retrieve them, as tags would
take care of it for them.
Don
Ian Roughley wrote:
So, a
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
That doesn't reference either of those interfaces -- but I think the
JSTL behaves very unpredictably given objects that implement both
interfaces. I can't remember the specifics, but since the syntax for
indexing list elements as well as map k
On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
It isn't about using Cocoon or "building another version of it", but
rather
learning from others design choices and consequences. I see Struts Action
2 as
a chance to quit "competing" and start "collaborating". Merging with
WebWork
was the first
No, the developers would use .info/warn/error to add messages, but I'm saying
they probably wouldn't need to retrieve them, as tags would take care of it for
them.
Don
Ian Roughley wrote:
So, adding the msgs.info("key") really isn't going to be used by
developers? The code below, if I am rea
So, adding the msgs.info("key") really isn't going to be used by
developers? The code below, if I am reading it correctly (not too much
experience with JSTL), will call the list or map for the
error/msg/warning directly and iterate over the elements.
So why do we need the additional methods?
From: Niall Pemberton <[EMAIL PROTECTED]>
Date: May 5, 2006 2:36 PM
Subject: Re: SAF 1.3.x and legacy RequestProcessor
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> >Its probably academic, but since CRP extends RP then it seems
> >incorrect to deprecate the whole class with a view to remov
Happily XWork has no dependency on web development at all, I use it to
provide a command pattern for autonomous path finding robots for
instance. Anything less than complete abstraction at the action level
would be vetoed by most of the existing developers. (At least I hope
they would vote it down
It isn't about using Cocoon or "building another version of it", but rather
learning from others design choices and consequences. I see Struts Action 2 as
a chance to quit "competing" and start "collaborating". Merging with WebWork
was the first important step, but equally important was Tim fr
Hello all,
My name is Brian Dittmer. I'm a third year Computer Science and
Engineering student at The Ohio State University and plan on applying
for the Google Summer of Code project and work on the Struts Ti
project. I've already talked with Patrick about some of my ideas but he
recommende
I will return to the boards shortly, I hope :-) But I've been
reading and need to address this:
Please be mindful not to buttonhole Struts into a servlet-only API.
One of the large efforts of the Tiles refactoring is to remove all
references of the Servlet API, so that it could be used in a portle
> Jason Carreira wrote:
>
> Either way, I highly recommend reading the two
> threads linked to by this
> Cocoon vote to use the servlet classes directly:
>
> http://www.mail-archive.com/dev@cocoon.apache.org/msg4
> 1132.html
>
> The cocoon folks are very smart and have been
> tackling this probl
>
> Yeah, this is very much like ValidationAware. I
> think it deserves a
> change because:
>
> 1. Messages should be independent of validation,
> however, validation
> hould be dependent on messages
Then this is just a renaming, because ValidationAware is just methods for
gathering errors
Jason Carreira wrote:
Well, I'm of the opinion that the Portlet API
specifically shouldn't have
extended the Servlet API, but I think there is
something to use implementing
Servlet API classes with Portlet implementations. As
I've previously mentioned,
this is the approach Cocoon is either l
Joe Germuska wrote:
At 7:34 AM -0700 5/5/06, Don Brown wrote:
But since this class implements List and Map, it is very obvious how
to retrieve messages:
${msg}
or
${msg}
Which class implements List and Map? org.apache.struts.action2.Messages
http://people.apache.org/~mrdon/action
Jason Carreira wrote:
Here is what I'm talking about:
http://people.apache.org/~mrdon/action2-api-don/org/ap
ache/struts/action2/Messages.html
I'm not sure I see enough of an advantage to this over say
ValidationAware from XWork to make it worth doing... I liked the
original idea on the "Roug
At 7:34 AM -0700 5/5/06, Don Brown wrote:
But since this class implements List and Map, it is very obvious how
to retrieve messages:
${msg}
or
${msg}
Which class implements List and Map? org.apache.struts.action2.Messages
http://people.apache.org/~mrdon/action2-api/org/apache/stru
Jason Carreira wrote:
For example, the Messages object, rather than
leverage the familiar Log
interface we all use every day. Messages are
collected, much like logging
messages and their levels are similar. Therefore,
we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error(
> Here is what I'm talking about:
> http://people.apache.org/~mrdon/action2-api-don/org/ap
> ache/struts/action2/Messages.html
>
I'm not sure I see enough of an advantage to this over say ValidationAware from
XWork to make it worth doing... I liked the original idea on the "Rough Spots"
page a
> Don Brown wrote:
> > re-education of developers. I want Struts Action
> Framework 2 to be seen
> > as easy and powerful, not just from a feature
> standpoint, but also
> > migration, education, and "conceptual space" one.
>
> I was talking to Eric on the ww dev chat, and he
> brought up a goo
Leon Rosenberg wrote:
On 5/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> ValidationAware, ErrrorAware, RequestAware, ResponseAware,
> SomeOtherStuffAware... Are you kidding? I might not understand
> something (heck, I haven't started with W
>
> It is generally possible to do both, perhaps through
> a configuration switch that
> controls whether to report errors on missing message
> keys or to treat them as
> the message.
I guess I don't really care about this one... Using keys all the time would
actually be easier for me, since w
Robert Leland wrote:
Eric Molitor wrote:
The new Messages API could easily be mapped onto an implementation
similar to that of Log4J. Why not embrace that idea and utilize
familiar methods to provide access.
such as...
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.ke
But since this class implements List and Map, it is very obvious how to
retrieve messages:
${msg}
or
${msg}
And of course we'd also provide the simpler JSP messages tags to make
that even easier. In fact, users of the UI tags won't ever have to
display messages, as they are genera
At 3:03 PM +0100 5/5/06, Niall Pemberton wrote:
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in the
future. Wouldn't it be more correct to deprecate all the prote
-- Forwarded message --
From: Niall Pemberton <[EMAIL PROTECTED]>
Date: May 5, 2006 2:36 PM
Subject: Re: SAF 1.3.x and legacy RequestProcessor
To: Joe Germuska <[EMAIL PROTECTED]>
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>Its probably academic, but since CRP extends RP
Eric Molitor wrote:
The new Messages API could easily be mapped onto an implementation
similar to that of Log4J. Why not embrace that idea and utilize
familiar methods to provide access.
such as...
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
Why not just:
I think this is ambiguous. In logging, you are always setting the
message. User farmiliar with log4j might think the methods below are
for setting error/messages/warnings and not obtaining them. I think the
getters and setters make more sense here.
/Ian
Eric Molitor wrote:
The new Messag
Its probably academic, but since CRP extends RP then it seems
incorrect to deprecate the whole class with a view to removing in the
future. Wouldn't it be more correct to deprecate all the protected
methods (e.g. processActionCreate(), processActionForm etc.)?
Perhaps we should consider what the
My understanding was that we may vote a relase as "beta" initially if,
for example, it has alot of new functionality and then if no issues
come up vote again to upgrade the quality to "GA".
Whats happened so far since this was introduced was that either
releases have been voted "GA" straight away
On 5/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> ValidationAware, ErrrorAware, RequestAware, ResponseAware,
> SomeOtherStuffAware... Are you kidding? I might not understand
> something (heck, I haven't started with WW yet), but if all thes
On 5/4/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 5/4/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote:
> >Looking at 1.3 internals (at last) I've found that it contains both
> >ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP).
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
ValidationAware, ErrrorAware, RequestAware, ResponseAware,
SomeOtherStuffAware... Are you kidding? I might not understand
something (heck, I haven't started with WW yet), but if all these
interfaces are only meant to implement a callback met
+1 for what Don is saying.
I've been heads-down updating the new wiki, so that when the code is
ready, the documentation will be too. The material on the wiki is
generally excellent, but there are "rough spots" there too, that I've
been trying to smooth over. Accordingly, I haven't been following
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by AndrewKuzmin:
http://wiki.apache.org/struts/Shale
--
* [:/UserDocs:
94 matches
Mail list logo
