I thought you read WebWork in Action ;-) There's a DB-driven ResourceBundle
described in there and in the source code for the book.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=50877&messageID=10271
> Its doable I guess.
>
> If we have an Expression parser / converter like Alex
> pointed out, we could have a standard syntax, but it
> would be more complicated to implement.
>
> Without an Expression parser / converter, it'd likely
> to get users confused as it depends on what
> implementat
>
> IMO, this is doable. But I think it may require yet
> another
> abstraction: an expression converter, as the engines
> you are
> mentioning are using different types of syntax. Or,
> if this is
> something that comes in the XValueStack
> implementation than I guess it
> may work too.
>
> ./al
>
> I'm happy to reintroduce a switch, but...
>
> - It won't be called "compatibility switch", which
> implies something else that isn't the root cause for
> concern here.
> - It will be classified as a "security switch".
> - It should be _off_ by default (meaning that it is
> the same as WW), c
> I might be missing some of the context and previous
> discussion, but thought I'd chime in anyway...
>
> I think this is a *terrible* idea. Great for crud
> apps, but as a very heavy user of webwork 1 (and 2,
> increasingly) purely as a *user*, commands (the !
> stuff) are very very useful.
To
> On 7/19/06, Patrick Lightbody
> <[EMAIL PROTECTED]> wrote:
>
> > Yup, the xwork profile is very nice for when
> generating the IDEA projects.
>
> Agreed, but ../xwork is not where my xwork lives. :)
>
> Any objection to making this configurable as a
> property?
>
> If you and Jason can add th
Talking to Patrick offline about the "!" handling, we had a discussion of the
direction we wanted to see things go. We were talking about our thoughts for
reducing configuration. He favored a single interceptor stack method with
annotations to specify parts to work or not work. My feeling is tha
> Ted,
> My opinion on this is that the ! syntax should be
> used strictly as a URL pattern and not anywhere else.
> That means we shouldn't name files like
> foo!bar-validation.xml, but instead figure out
> another way to map it to a context.
>
> Currently, you can name those files
> "foo-bar-val
> ...unless you really want to take the security
> exercise all the way,
> i.e., secure each and every method via
> container-managed security using
> annotations (ideally) to configure what roles/users
> can access what
> methods, thereby taking the URI out of the equation
> entirely... if you
>
> My understanding was that wildcards was much more
> about reducing configuration and introducing
> conventions rather than addressing any perceived
> issues about multiple entry points on the action.
>
You say "multiple entry points on the action" like you can't have that without
the "!" n
>
> Christ - I have proposed things, many times. Why are
> the words "annotations" and "convention" being
> ignored by everyone. Let's try one more time.
>
> 1) Convention-based protection: only allow methods of
> the form "String doXxx()" to be called via the
> request.
> 2) Annotation-based pro
>
> Following up to myself: I want to also make it clear
> that I'm not opposed to changing my way of doing
> things, but so far I haven't seen anything that seems
> any better than what I'm doing now. I'm happy to
> explain more about how the ! syntax is used with all
> my forms, so that alternat
>
> First off: we're *not* deprecating and removing the !
> notation at this point. That is what this discussion
> is entirely about.
Not YET... that's what the conversation was about as I read it... when, not if.
>
> Why not disable getters and setters by default too
> and require people pull
> I guess why I don't like this mentality is that we
> have these kinds of security holes all over the
> place. If you expose getters or setters that are
> unsafe in your action or _any_ of your model objects,
> you can get that problem. The fact is that with
> dynamic reflection that is controlled
> Ok, this issue breaks down like this in my mind:
> 1. Should our tags (url, form, etc) have attributes
> for the
> amespace, action, and method, or just have one for
> the url?
> 2. Should our default ActionMapper allow the method
> to be specified in the url?
> Issue #1 goes back to the more f
> On 8/23/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> In my five-day class last week, we spent most of the
> time covering
> Struts 2 from the ground-up, and I made comparisons
> to Struts 1 along
> the way. The course uses the MailReader as a running
> example. On day
> five, after we had built
> OK, I've been lurking on this list for some time, so
> nobody here knows me,
> but I do want to weigh in on this issue on Jason's
> side. I'm relatively new
> to WebWork, using it for a new Web application
> project started in March. I
> was responsible for evaluating the various frameworks
> ava
> Ted, while I have no opinion on case, I can say that
> my comments in these threads has been driven entirely
> from real world experience. This URL:
>
> https://struts.hostedqa.com/project/7/session/suite/li
> st
>
> Maps, via conventions, to
> com.hostedqa.action.project.session.suite.ListActi
> We can be rigid and consistent in the conventions
> that we use with our
> own examples, but the nature of wildcards implies
> that people could
> adopt other conventions, whether we like it or not.
> :)
>
> And, the nice thing about people being able to adopt
> their own
> conventions is that i
> On 8/3/06, Jason Carreira
> Ted didn't say deprecate. Ted said that it didn't
> seem like a best
> practice, in the same way that chaining actions is
> not a best
> practice. Mainly because it goes against the grain of
> the "advanced"
> feat
If it looks like the stuff Don was showing before, then it's looking too
complex.
Either explicit configuration or easy but rigid conventions... not configurable
conventions ;-)
-
Posted via Jive Forums
http://forums.opensympho
> I think you missed the main point I was trying to
> make, which is that the concepts of multiple stacks
> is something I avoid entirely. Instead, I believe in
> one stack that is capable of providing different
> behaviors based on conventions.
No, I understood that... I just don't agree.
---
Either way, you're still talking about multiple aliases for one class, which is
what Ted was saying we should deprecate.
For how it's done... Well, I hate the "!" notation... We've had to jump through
a lot of hoops to support it and it still bites us every now and again. Plus,
it's just a sec
> Jason, I have to disagree with you on this. I've
> written a lot of WebWork apps and multiple aliases is
> rarely used (maybe 1-5% of the time for me). Perhaps
> you can give the common examples you come across so
> that we can understand your style better?
>
I think I posted this last week, bu
> I'm not suggesting that try to make it impossible to
> use multiple
> alaises. But I am suggesting that the Struts 2 group
> should recognize
> that multiple aliases are not a recommended practice,
> in the same way
> that chaining actions are not a recommended practice.
>
I disagree. Multiple
> On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > Patrick and I talked about doing that, however, we
> came up against several
> > roadblocks:
> >
> > 1. How would you handle nested packages? For
> example: /foo/bar/joe?
>
> Do we need to handle nested packages?
Yes.
>
>
> > 2. How wo
> The modifiers could solve problems 3 and maybe 1
> ("com.acme.{1|slashesToDots}.{2|capitalize}"), and
> perhaps #2 could be solved by
> using the "!" separator instead of the "/" again.
>
> However, the question must be raised whether these
> improvements obscure the
> somewhat advanced wildc
> I would think an ideal application would have the
> following:
>
> - zero configuration (using conventions instead) for
> actions and results
> - overrides possible in struts.xml, including
> wildcards
> - result overrides via annotations if struts.xml is
> too verbose
> - annotations for valida
> Ted,
> Good questions. Related to that - why is it than i18n
> resource bundles are tied to the action class rather
> than the _view_ (the view would tend to make more
> sense, I believe).
In practice I've found it makes more sense to keep them at a higher level... we
keep one resource bundle p
-1 on giving too many options.
The validation framework gives a way to do validations. You can also code your
validations in Java, or build your own hooks into any other validation
framework through interceptors.
Remember, while it seems nice to let people choose from an array of options for
> Being able to return Result instances from Actions
> doesn't
> necessarily mean the lack of reuse of Results. This
> is equivalent to
> saying that because it's Java code you can't reuse
> it. I didn't
> realize that XML was the solution to lack of reuse in
> OO ;)
>
> Seriously though,
> > Oh please no... please no abstract methods with
> magic implementations. What happens when you go to
> debug the class?
>
> The debugger would step from your action into the
> result. You rave
> about Hibernate and AOP; how do you debug those?
>
It's one of the biggest problems with them. We
> Could you give an example how multiple mappings for a
> single action is
> used with common CRUD actions?
>
> Don
Ok, here's what our Invoice CRUD action mappings look like:
/template/eplus/metaDataList.ftl
>
> Though, I would strongly suggest that we try to
> follow the Stripes
> annotations wherever possible. And if there's a hard
> reason why we
> want to use a different term, we should work with Tim
> on an
> alternative. There's really no reason to have two
> annotation APIs that
> are trying to
> I'm sure some people do, but the question is in what
> percentages? I have done
> it, but only a couple of times, perhaps representing
> 2-3% of my actions. Since
> the XML configuration way is still an option, I think
> orienting the framework to
> make the more common things easier, yet st
> Instead of returning a Result object, we can also
> consider calling out to a
> result method. This is how Rails works. For example:
>
> class FooAction ... {
>
> Foo foo = new Foo(); // populated from request
> parameters.
> public void create() {
> if (foo.isValid())
> redirectTo("Li
prefer the old style, they would still have that
> option.
>
> Don
>
> >
> > -t
> >
> > On Jul 25, 2006, at 4:11 PM, Ted Husted wrote:
> >
> >> On 7/25/06, Jason Carreira
> <[EMAIL PROTECTED]> wrote:
> >>> @Action to ma
>
>
> Works for me. What should we call this annotation?
> @Published?
@Action to mark it as an Action method?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=38338&messageID=75682#75682
--
> I'd much rather annotate methods which can be called
> than specify them in
> XML.
>
> Also, this doesn't pose much of a security risk in
> practice as it only
> applies to public, no-arg methods which return String
> in actions.
>
> Bob
>
No-arg, yes, but it will convert anything else to a S
> I don't often reply to messages on these lists, but I
> feel like I
> have to offer a (relatively) outside perspective
> here.
>
> There's been a lot of confusion external to apache
> about what's going
> on with Struts. With Shale moving to a TLP, that's
> helped, but I
> think a lot of
> On 7/23/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> > If we want to tag now, the new API will have to
> wait for 3.0.
>
> I think we are reaching the point where if we still
> want to make
> "large changes" for 2.0, we need to make them now,
> or make them in
> 2.1. AFAIC, we can open 2.1 as soon
> For Struts 2, the example apps are no longer part of
> the default build.
>
> To build them, add -Papps (or -Dapps, if you prefer
> system properties)
> to the command line.
>
> (Or, cd to the 'apps' directory or below and build
> with 'mvn' as usual.)
>
> Is anyone using the 'xwork' profile t
Ok, well, I can ask if we can contribute them.
> Ok, if people are ready to do the work now, I'm fine
> with adding them. The
> background on this is I want to get the 2.0.0 release
> out by the end of the
> month. While it will probably just be a an alpha or
> beta, we still have a lot
> of
:-) I wasn't the one volunteering...
Putting the tree tag in took a lot of time, and I didn't even document it ;-)
I'd say these can wait.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=37315&messag
Well, the tree was the most complicated one, and we did contribute that one.
Other than that it's the common stuff:
* Checkbox group
* Tabbed Panel and Panel
* Wizard and Wizard Step
* Table and Column
Along with custom templates for the other UI tags for things like in-page
callbacks before a
This was a long-time goal we had, but, as you noticed, it's not so easy and it
breaks backward compatibility (which is ok now, but wasn't before)
Another thing to add to your list is the type converter, which is stored in a
static instance.
If you see a good way to break this up into pieces, I
>
> Yes, we do seem to have a JAR bloat issue with Struts
> 2. On disk, the
> S2 applications run *twice* the size of comparable
> S1 applications.
> (Though, that does not mean the memory footprint is
> different!)
>
> Why is that? Are we sucking in any runtime
> dependencies that we don't
> ne
+1 for this
I'm surprised Maven can't build a source distribution with a bundled standard
ant build with maven dependency ant task calls. I'd think this would be a
common need.
> The one case I wouldn't mind seeing an Ant build is
> in the source distribution.
> Many times, I'm downloading s
What's an "archetype"?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=36179&messageID=70902#70902
-
To unsubscribe, e-mail: [EMAIL
Can someone add to that page the instructions for setting up Idea projects and
especially the magic incantation needed for it to build one for XWork if you've
got it in parallel with Struts 2...
-
Posted via Jive Forums
http://fo
> From memory (WW in Action) there seems to be similar
> concepts in
> Cintoo messages that WW/SAF2 has - but I was hoping
> someone who knows
> would comment.
>
> The license is Apache 2 and it looks good to me - is
> this something
> that SAF2 would benefit from or is that area already
> well co
> +1
+1 to which? ;-)
I'm for just calling them Struts 1.x and Struts 2.x, not the Struts2 version
2.1 idea. We went through that for a while with WebWork, and it was confusing.
-
Posted via Jive Forums
http://forums.opensymphon
> I did think about it, and it's not logical. Why do I
> want to lump getters
> and setters together to fit some artificial notion of
> a "property?" The
> answer is I don't. I don't think there's a
> justification for doing so that
> matters to users, and there are plenty of reason for
> a getter
It has to do with the java.beans.Introspector. It doesn't find the properties
correctly if the getter and setter don't match. It won't be able to figure out
what the property type is if they aren't the same for the same name. I don't
remember what the heuristic is, but if you think about it, it
>
> 2. The current Dojo based widgets are simple enough
> to be used in some
> sample/tutorial like pages but for real life apps
> they don't work (or
> put it in another more realistic way: I haven't been
> able to have them
> working within a normal timeframe).
> I have to mention, that I haven
See below:
>
> 1. For very basic wrapped widgets the dojo
> implementation is great.
> But, as soon as people start working more in depth,
> problems arise and
> in-depth knowledge of the dojo framework is required.
> I believe Pat's
> xamples of this was debugging issues. This no longer
>
> I see your concern.
>
> I don't use doXXX and extends my custom interceptor
> off Interceptor interface, so it wouldn't be of any
> impact to me, but I am not sure about other WebWork
> users.
>
> Since this is a SAF2 release, I'd prefer to either
> remove them totally or keep them, rather than
I don't think JarJar fixes the root problem: 2 API level incompatible libraries
(Xwork 1.x and Xwork 2.x) with the same packages. Just because we fix it for
SAF2 doesn't fix it for anyone else that wants to use XWork 2 and WebWork 2.x
separately.
-
> Is this really an issue? If users are running WW2.2
> with Struts2
> everything should be fine, so this case will be only
> when running WW2.0
> or WW1 with Struts2 - correct? And it would only be
> a problem when
> running in the same web application (and thus same
> class loader).
>
> I'l
> Well, it would have made Atlassian's life easier.
> JIRA is written with
> WW1 and Confluence is written with WW2, the two
> versions cannot
> coexist in the same web application, and they still
> haven't gotten
> around to migrating JIRA. When people (like me) run
> both applications,
> we need
> I looked at how to make that change, but I think we
> still need to do some work
> with xwork's config. It makes heavy use of this
> XWorkStatic class with static
> retrieval methods. Worse, the static use creates a
> circular dependency between
> ConfigurationManager and DefaultConfiguratio
>
> WebWork has a Jasper result[1]. It was not
> transitioned to Struts
> Action 2 because of the licensing issue. The code
> should be readily
> adaptable for those who want to use it, and perhaps
> it could be kept
> alive either as part of Jasper Reports' development,
> or in a
> SourceFor
>
> Ted and Jason, I did see your messages about
> AroundInterceptor and
> Result correspondingly... right now, in the interest
> of simply getting
> it working, I'm just doing a simple AroundInterceptor
> using before() and
> after(), one interceptor for XML and one for JSON
> (although as I j
> >Is the shopping cart app using JSF? I thought Don
> only added it to
> >the showcase.
>
> I think it is because some of the interceptors
> defined struts-default.xml is using JSF stuff, SAF2
> will throws exception when loading the interceptors
> that requires JSF dependencies.
>
I just brok
>
> It's been talked about here, but I don't know how
> much interest there
> might be... At this moment I'm grabbing the code I
> started and intend to
> finish it this weekend...
>
> My plan is to create 4 interceptors. Two for input
> and two for output,
> one each for XML and one each for JS
>
> No, I definitely would love to see ajax support...I
> just think it needs
> to be done right. Integrating DWR looks like it
> might get a bit messy.
> Taking ideas from DWR, maybe even some of the code
> and/or the js libs,
> and building the support directly into SAF2 would be
> a better
> > but if you want to model best practices, then you
> have to ask "why
> > would you be intent on calling Actions"? I'm not
> trying to build
> > walls so that people can't just get-the-job-done,
> but I do know from
> > experience that people tend to overload Actions
> with too much
> > busines
> Yep, we should branch XWork before you commit your
> changes. Shall I
> create a branch of the current CVS as XWORK_1_2?
> So you could commit your changes later into HEAD and
> Patrick could
> start the migration to SVN after this commit.
>
> Rainer
+1 (if we're voting)
---
>
> It also may be wasted work if there's an idea that
> the whole
> repository may be moving again (that is, to Apache)
> in 6 months.
Exactly, point #1.
>
> That said, I recall people generally saying that the
> SVN
> import-from-CVS tools work pretty well, and they also
> are able to
> pr
Why move it to SVN? What does it gain? Just wondering how I'm going to
reconcile all these changes I've got that will be harder to do if we switch
repositories...
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jsp
> Agreed. Are we going to move XWork to Subversion for
> 2.0 or stick with
> CVS for now?
>
> Don
>
So then that's a couple of questions:
1) Do we want to move XWork over to Apache SVN?
2) If not, do we want to branch XWork's CVS for a 2.0 branch, or do we want to
move it into a different r
Wendy, will this create the IDEA modules with all dependencies for extras and
showcase? Are all of the jars downloading now? I had to fix this by hand on the
plane yesterday, so I don't want to blow them away if I have to do it again.
> Be sure to update and install from the top level of
> Actio
> Don, this is *very* interesting. Nice work. I've been
> wondering for a
> while if we could reuse off-the-shelf JSF components.
> It looks like
> you may have figured out how!
>
> It also proves that you can think of the JSF
> lifecycle as a more
> complex, higher level of abstraction of our
> i
So on the plane home I was able to get some work done. Well, first I had to set
up lots of libraries for the extras and showcase modules, since maven didn't
set them up, but then I got some work done. (BTW, can we get that fixed, along
with the problems downloading libraries?)
So anyway, I did
>
> I have a couple of comments to make about this.
>
> First of all, presumably the whole motivation of this
> "merger" is that
> you could unite your energies on a common framework.
> If there is still
> ongoing work on 2 different frameworks, it kind of
> belies the whole
> point of the mer
> Let's not exaggerate the impact of the API on user
> code though...
>
> Users record validation errors a little differently;
> you should be
> able to port existing WW2 code pretty easily with
> some clever
> refactorings (which we will document when the time
> comes).
>
> And we're trying to s
> Please don't judge until we are done. We need to
> first agree on our
> design goals, then we can pick through
> implementations. The proposal is
> about agreeing to the laid out design goals, but it
> is too early to say
> that we are or aren't meeting them. First cuts are
> never put into
> Don't worry, David. We're just talking about cleaning
> up the API and
> making your code a little cleaner. It's fundamentally
> the same
> framework with the same philosophies.
>
> Bob
>
Maybe the same philosophies, but the API you laid out is very different for
users of the framework...
---
> 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 t
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
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
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
> 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
>
> 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
er Cocoon
> did, but there is value in
> learning from how they tackled a similar problem. In
> the end, we may go with a
> new abstraction layer, but it is still important to
> make that decision fully
> informed.
>
> Don
>
> Jason Carreira wrote:
> >>
> 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
>
> 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
> 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
>
> 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
> We're using WebWork 2.2 heavily on a handful of
> projects (OK, a big
> handful of big projects), so I definitely understand
> the concerns.
>
> I didn't mean to shock anyone. I thought my point of
> view was clear
> based on the introduction to the "Rough Spots" page
> (http://wiki.apache.org/s
>
> How do you envision that working? Would individual
> messages have an
> optional "severity" property? (i.e. "error",
> "warning", possibly
> others) Or would there be one bundle of messages for
> each severity?
>
> I've taken to using a generic BusinessProcessResult
> object (sometimes
>
>
> Ok, what about passing in an instance of Messages,
> MessagesAware, or something
> similar?
>
Well, currently the validators are passes a ValidatorContext when they are
created. The ValidatorContext includes methods for adding messages as well as
methods for getting localized texts, etc.
I agree with Don on almost everything... scary!
The exception is the validate() method returning messages... we need a central
place where messages are added, not passing them in and out of methods.
I was also confused by the Request interface... I thought / expected it was
going to be a way to
Ok, I remember us saying we wanted to clean up a lot of things that weren't
right in the old codebase, but why are we changing everything just for the sake
of change?
Instead of having a pretty good sized community who can easily switch over with
a few tweaks (the WebWork community) and a huge
Not sure about the requirements you're talking about, but it should make almost
everything easier when programming to the config APIs, so I'd hazard a guess of
"yes".
-
Posted via Jive Forums
http://forums.opensymphony.com/thread
Ok, so I'll bite... What's "Girders"?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=27484&messageID=56099#56099
-
To unsubscribe,
Speaking of which, I was planning on doing some work on XWork configuration
refactoring and making it runtime changeable along with removing some
singletons on my flights to SFO for JavaOne... Any objections?
-
Posted via Jive Fo
Where's the link on the wiki? Does MoinMoin support rendering items from an RSS
feed in a page?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=28611&messageID=55624#55624
---
1 - 100 of 112 matches
Mail list logo
