Jing Zhou wrote:
I am wondering how I could implement a jump behavior in the main
chain. The use case for a jump behavior is that the main chain should
continue with several commands skipped over. For example, I would like
to jump to the last command in the main chain after the current command.
a method in Chain that allows us to execute
the chain starting with a given index (currently
the starting index is 0). Will that make the thing simple?
Or the idea is still disturbing somewhere?
Jing
Netspread Carrier
http://www.netspread.com
--
Ted Husted,
Junit in Action - http://www.manning.com
Steve Raeburn wrote:
I'd like to add Maven now, learn from the experience on 1.x and then
use that to optimize the project organization and build process for
version 2.
If the people voting +1 are ready to roll up their collective sleeves
and give Maven a try, then that would be fine with me.
Don Brown wrote:
Further, deciding between Forrest and Maven isn't an either/or situation.
There exists a Forrest plugin for Maven and it would be easy to integrate
Maven's reports into a Forrest site build.
.../
If we did decide to go with Forrest, I'm willing to convert the old site
over and
To discuss whether a feature might be a good idea, you can post here.
Though, it can take several days before everyone weighs in. We're all
volunteers with real jobs. Many of us can only work on Struts on the
weekends.
To raise and fix issues, you can post tickets to Bugzilla. This is where
Don Brown wrote:
For example, currently, we have quite a few Struts extensions, example
applications, and related frameworks that I feel Struts could do a better
job of encouraging. Instead of requiring an extension developer to submit
a patch to bugzilla to change a description or add their
Chris Gastin wrote:
I have to agree with David. Lets find one way to do it and make it simple,
if a build process can be. I have worked a little with Maven, and it seems
tobe simple. I am not knocking Forrest. I have not had a chance to look into
it. If that is more simple than Maven then I am all
Robert Leland wrote:
The whole Maven idea came because we felt the build
process of ant struts-legacy was broken or needed some
serious work. If Don wants to put energy into redoing our site's look
and feel that then here is my +1. Just know we are still
left with the original problem.
Don Brown wrote:
Yes, this won't help our build at all. Until we get Maven running, there
are some options to bring some Maven features over to Ant. For example,
if we wanted to get rid of jars in our CVS, we could use something like
http://www.krysalis.org/ruper/ or
Chris Gastin wrote:
Where in the CVS tree is the struts-html.tld file that needs to be
modified when adding attributes to a tag.
What we do is maintain the TLDs as XML documents and then use a style
sheet to generate the TLD and the HTML documentation. So, they are
hidden in the documentation
I'm not sure that it matters. We're pragmatic when it comes to Bugzilla,
so whichever is less work for you, should work for the rest of us.
Volunteer time is our most precious resource.
The dependency feature is relatively new, and we haven't come to
depend on it ourselves yet :)
-Ted.
Chris
Joe Germuska wrote:
Looking to Struts 2.x, I am thinking that the ForwardConfig would merge
with a ViewController, and that instead of the Struts action returning a
ForwardConfig, it would return a logical name (String); then the details
(and potential complexities) of dispatching to any chosen
Jing Zhou wrote:
- A well designed framework should not have overlapped
concepts, or terms that lead to overlapped concepts.
We have the concept of action controllers, we should not
have more *controllers* when a view is under preparations.
IMHO, a well-designed framework should provide
Just a heads-up: The discussions about the short 2.0 license are
heating up again. A good time to catch the 1.0 licenses would when 2.0
goes through. In the meantime, as Rob says, new development should use
the 1.1 license
http://www.apache.org/licenses
with #4 modified to read:
* 4. The
Steve Raeburn wrote:
Contributors List
-
One side effect of merging the XSL stylesheets is that the contributors list
is currently not written at the start of each chapter. (Some stylesheets had
it, some didn't so I opted to remove it from the chapter section.)
I wondered what the
Steve Raeburn wrote:
Done.
The ASF thanks you for your help and support =:)
Hey anybody going? I won't make it this year, but I'm starting to think
about 2004.
Regarding the archived 1.02 docs - there doesn't seem to be a link to them
anywhere. Shall I add one?
We should probably remove those
Steve Raeburn wrote:
I wasn't saying that the existing tags can't or shouldn't be extended. Just
that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta
Taglibs, because they are dependent on Struts.
Jakarta Taglibs maintains a Dreamweaver extension, why could they not
maintain
Robert Leland wrote:
Over 99% of commons-validator usage is through struts. In fact it may
be 100%. I feel the only way to really promote commons-validator to
Beta status is to make the nightly build of struts depend on the 1.1.0
version which has released in Augustand been designated an
in something like o.a.s.view, but if it's
going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
I'll post more on this later, but to avoid the gotcha, I'm now
thinking we should try this using a modified ActionMapping.findForward
method. In that way, all the navigational
Once upon a time, I made a point of updating the changelog, but during
that death march affectionately known as the Struts 1.1. release =:), I
fell out of the habit, and haven't picked it up again. Back in the day,
some thoughtful people also tried to update the changelog as they made
the
.
Thanks,
Chris Gastin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts
Vic Cekvenich wrote:
(also IMO Struts HTML and tiles tag could/should migrate to taglibs)
Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs,
in the same way that the Struts View Tools are maintained by Velocity.
Struts should make it as easy as possible for presentation
this?
Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com
Steve Raeburn wrote:
While I'd probably be in favour of Struts becoming a top level
project, I must confess I don't quite understand the criteria for
becoming one.
It's mainly a question of whether the community surrounding the product
is mature enough to stand on its own and stay true to the
Maybe we can wait until it's time to add a form of validate that will
just take a mutable ActionContext and return void, and deprecate it all
at once.
Robert Leland wrote:
David Graham wrote:
Only ActionError was deprecated, not ActionErrors. We still need to use
ActionErrors because the
(at least for new projects), but what about
validators?
Regards.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol
These types of questions are best asked on the Struts USER list.
http://jakarta.apache.org/struts/using.html#Lists
khabot zakaria wrote:
Hi,
How to create a bean corresponding to a tagLib, and how to generate an Action like
/logon.
Thanks..
--
Ted Husted
Don Brown wrote:
Regarding wildcards
(http://issues.apache.org/bugzilla/show_bug.cgi?id=21813), I decided
to hold of on putting them as it seemed a 1.1.1(2?) was around the
corner. However, as it looks like it is not, I'd like to put it in
this weekend.
It sounded to me like this code was
Chris Gastin wrote:
As I can tell from the list I have opened topic that is pretty well
beaten. Let me first apologize. I did not realize this was such a
political topic in the Struts community.
There was a time when we were encouraging people to use the JSTL, and
there was a political bent
Sgarlata Matt wrote:
Of course if I really want that I should probably just use
Velocity, huh? ;)
+1. I do =:)
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
In the beginning, there was no Jakarta Taglibs, or inkling of something
like JSTL. So, Craig bravely put together a useful implementation of
some custom tags that did two things. First, they exposed the internals
of the Struts Controller framework. Second, they provided some basic
It is becoming commonplace to use an Action as a front for a server
page. This is not what people mean when they talk about Action chaining.
Some people start to use the Actions as finely-grained business actions.
For example, they want to accomplish a move by forwarding to a
copy Action and
Personally, I would tend to use a coarse-grained bean that contained the
properties for both pages.
But, AFAIK, calling RequestUtils.createActionForm directly is
sanctioned, especially as a way of obtaining a DynaActionForm.
-Ted.
James Turner wrote:
I haven't seen anyone mention the most
it the output from that form so
that it can tender a default validation.
-Ted.
Peter A. Pilgrim wrote:
Ted Husted wrote:
I working on something similar right now too, but using the FormProc
package. I believe that we should represent entire input form in XML,
including things like the default
Sorry to confuse you, Peter. Apparently, I'm not being clear.
FormProc is a SourceForge project http://formproc.sourceforge.net/.
It's a mature library that is used by the JPublish Framework and
distributed under the Apache License. It is designed to capture a list
of parameters, validate
: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512
I working on something similar right now too, but using the FormProc
package. I believe that we should represent entire input form in XML,
including things like the default control type and field labels, and so
forth, along with prompts, error messages, validations, and type
conversions.
it a little, but nothing radical, so I think
I'll sit back and see if people see this as Struts 1.3-ish material, or
whether it needs to ferment longer...
Joe
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site
loading of message resources truly a bug? Can't struts handle
multiple sets of properties per module?
Answers, suggestions and workarounds would be most welcomed!
Thanx!
jeff
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512
On Sat, 13 Sep 2003, Niall Pemberton wrote:
I may have got the wrong end of the stick, but doesn't Struts overlap to
some degree with JavaServer Faces and wasn't there talk of perhaps Struts
evolving to be a implementation of JavaServer Faces?
Craig R. McClanahan wrote:
That's certainly a
Ted Husted wrote:
Personally, I would suggest that if people were interested in an Apache
implementation of JavaServer Faces
Neglected to mention that there is, of course, the MyFaces project at
SourceForge
http://sourceforge.net/projects/myfaces
but current work is under the LGPL.
http
Craig R. McClanahan wrote:
* As a completely new and separate project, commissioned through
the Apache incubator process, with an ultimate destination of
either Jakarta (as a subproject parallel to Struts) or as a
completely separate Apache Faces project with its own PMC (like
Ant,
] wrote:
On Thu, 11 Sep 2003, Ted Husted [EMAIL PROTECTED] wrote:
As it turns out, we just have a wrapper page on j.a.o that calls a
script on the main apache site, to which I do not have karma =:(
But the script uses the page in jakarta-site as a template. You will
want to modify xdocs/site
for others.
Could we realize this dream? I know there are many
challenging problems there. Could we think about it
in terms of defining characteristics of Struts 2?
Jing
Netspread Carrier
http://www.netspread.com
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:36 PM
To: 'Struts Developers List'
Subject: RE: Where is Struts 2 going?
Where the heck is this new Commons-Chain? I don't see it in CVS or on the
website. Sounds like the next big thing from Jakarta.
--
Ted Husted,
Junit in Action - http
With an update to Ant 1.5.4, it now WORKSFORME with both 1.4.1_03 and
1.4.2_01. The validation step takes a few seconds, but I'm OK with that.
I'm posting the new version now. Thanks Steve! It looks great!
-Ted.
Steve Raeburn wrote:
Thanks James, I'm about to commit an updated
://sitebuilder.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html
Right now, we use scp to either send up the files or a WAR to burst.
This requires karma to jakarta.apache.org, which root no longer hands
out as a matter of course, but should be available for the asking.
The Jakarta site2 project uses a system where you can checkout the HTML
pages from CVS,
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512
the message from
the session
would need to be syncronized. This doesn't have to be a plugin.
-Rob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http
be too difficult to add back if that's what's wanted.
Let me know what you think or if you find anything I missed.
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted
with no problems.
Steve
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: September 10, 2003 3:58 AM
To: Struts Developers List
Subject: Re: XHTML Web site updates
I'm fine with all this generally, and was going to post the update, but
I'm having trouble getting
sure we'll be
using something else
Please let me know how much you intend to charge in royalties, or, if you
are not the proper copyright holder, please lend me his/her name...
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts
Robert Leland wrote:
Joe:
Thanks, I was hoping you would chime in ! It looks like you used maven
for your site, and I prefer your color scheme over the standard...
Which is here, if anyone was wondering:
http://demo.jgsullivan.com/struts/
-T.
in moving the 1.x documentation to Forrest, I wouldn't be opposed.
-Ted.
(Just a random thought, would either Maven or Forrest care that how we
generate the taglib API documentation from the TLDs?)
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http
David Graham wrote:
I was under the impression that the blue/grey lf was the new Jakarta
standard that sites would be moving to. Maybe it's just the default Maven
lf that no one ever bothered to customize. Both the Maven and Forrest
lf are fine with me; I'm just a big fan of consistency so if
Robert Leland wrote:
I am strongly in favor of moving to maven now, and will help where I
can.
My only concern is that we continue to view Struts 1.x as being
evolutionary mode. If we have a consensus on this point, then we should
all be careful that we do nothing that will break the build or
Robert Leland wrote:
Do we want to hold a formal vote/lazy consensus on what doc
system we are moving to ?
Don already put the Struts SourceForge site on Forrest, so I would lean
in that direction.
http://struts.sourceforge.net/
http://xml.apache.org/forrest/
-Ted.
Craig R. McClanahan wrote:
Or, to put it another way, using Maven as a
build system will give us a website/docs publishing system for free.
Well, last I knew, TANSTAAFL. =:)
It's nice that Maven has a build system, so long as it's a build system
that fits our needs. Likewise, it's nice that
Craig R. McClanahan wrote:
Sorry for the late response on this ... it seems like weekends are the
only time I get to play with open source code any more :-(.
I hear that, brother! =:0) The catch-as-catch-can thing isn't working
for me anymore either, so I think I'll take my own advice
Craig R. McClanahan wrote:
I'm -1 on making Struts 1.2.x dependent on Servlet 2.3 / JSP 1.2.
Ditto. Contrary to popular brief, a great number of organizations have
*not* migrated to 2.3/1.2, including some of the largest companies in
the world.
-Ted.
Robert Leland wrote:
Shall we move to Validator 1.1.0, for 1.2.0 ?
If it makes it from Alpha to GA in time, and it's a drop-in replacement,
then it would be OK with me =:0)
Though, I'd like to get out at least one 1.2.x point release before
doing anything drastic, like migrating to Commons
_ /|\
soapbox- |x| / \ - me, no longer on it :-)
Steve
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: August 29, 2003 1:44 PM
To: Struts Developers List
Subject: Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
- Enhancement of the html:link
distribution, which would then
be used in both environments.
Should Struts 2.x aim to be a portlet framework as well?
Mete
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec
commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512
It's my feeling that Struts 1.x has to support 2.2/1.1, because that's
where a significant number of users still live.
But, it's also my feeling that the refactoring of the Request Processor
could open the door to being able to offer more than one front
controller for Struts 1.x.
The default
David Graham wrote:
IMO, Struts 2.x should attempt to get out of the taglib business
altogether. Until then, we should just let the tags be and maintain
Struts 1.x as Servlet 2.2 minimum requirement.
+1
And along the way, we can start distancing the core distribution from
the taglib
So, I'm getting back to work on this now.
I'm reviewing the documentation now, to be sure there aren't any
dangling issues there before getting on with the usual Bugzilla /
Changes gauntlet.
Following up on the post to the User list, I'm adding links to the
Struts Wiki where people can post
that resolving these tickets is an
important part of community-building, but that's just me =:0)
-Ted.
Ted Husted wrote:
AFAIK, the consensus is that our releases should follow the same
general process used by the Jakarta Commons and the Apache HTTP Server
project.
So, for reference, I'm
Steve Raeburn wrote:
The problem with adding a 'parameter' is that you then find a need for
another parameter, etc etc. Is set-property not suitable here? Or, even
better, nested configuration elements under form-bean.
Yes, set-property would work here, just like everywhere else. I'm just
saying
(although for 1.1 we'd probably implement all this inside a new one
that simply replaces the process() method with the appropriate chain
lookup and execution.)
For clarity, we probably should be saying the 1.x processor, since we'd
certainly be past 1.1.x before anything like this shipped.
Stuff symposiums.
I look forward to checking out the Struts2 architecture and code as it
evolves.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit
In terms of simplifying the maintenance of DynaActionForms, I was
wondering if we had tried anything like this yet?
form-bean name=inputBean
type=org.apache.struts.validator.DynaValidatorForm
proxy=com.mycompany.project.businessBean /
where the proxy class would be introspected, and String
, 15 Aug 2003, Ted Husted wrote:
In terms of simplifying the maintenance of DynaActionForms, I was
wondering if we had tried anything like this yet?
form-bean name=inputBean
type=org.apache.struts.validator.DynaValidatorForm
proxy=com.mycompany.project.businessBean /
where the proxy class
I'd say it was more like a poll to get an early consensus on the best
name for the class. Any product change would still be subject to a veto
before the next release.
James Mitchell wrote:
Is this a vote? If so, shouldn't we have [VOTE] on the subject line?
I *think* we agreed to add this
such a Response and leave
the Action class out of it.
So, the best practice would be that the Action class should never touch
the Response or the ActionForward path, that would be up to the View class.
-Ted.
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action
David Graham wrote:
We already documented this in the 1.1 @deprecated tags. I don't think we
need more documentation on the deprecations.
Then maybe the best thing is to post the Alpha and ask people to tender
their vote as to whether it should remain an Alpha, go to Beta, or go to
General
First, I don't think there's anything wrong with our defining the term
success to indicate a nominal outcome. Java does the same with terms
like true and false. I'd also submit that that SUCCESS and FAILURE
in Globals would be a clear demonstration of an important best practice:
Use
should try to branch to another page, like an Action
might, if there's an error. But the declarative exception handling might
be able to step in here.
-Ted.
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site
David Graham wrote:
No, I was thinking Actions would be passed an ActionContext in their
execute() method similar to how Servlets know about a ServletContext. The
ActionContext would contain the HttpServletRequest, form bean, etc. and
would serve to keep the API stable while allowing flexibility
.
5) I spouse, reset() is in most cases not very much quicker as making
new instance. In any case, instantiatation of new form occurs relative
seldom.
I think, we schould remove recycling of ActionForms and reset() schould
be deprecated.
--
Ted Husted,
Junit in Action - http://www.manning.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos
Craig R. McClanahan wrote:
One of the potential problems in a Context-based environment is knowing
which keys you are using to store and retrieve stuff -- obviously, the
producer and consumer of a piece of data need to agree. It is also
important that people looking at a Command should be able to
Steve Raeburn wrote:
I'm for removing it. I can do this if no one else is on it already.
David said he thought I was going to do it, and I thought David was
going to do it, so let's split the difference and let Steve do it =:)
-Ted.
My only concern would be using the term context to imply more than one
object.
IMHO, there should be a functional non-httpd framework below Struts,
that would provide things like a Context Object, which would be a
generic version of the HttpRequest. At the Stuts level, you could then
have
Craig R. McClanahan wrote:
Tomcat's 4.1 experience was that only every sixth release or so was voted
GA, at least for the first several.
I think if you look at the various Betas and RCs most Jakarta products
go through, six would be the mode. So, this seems pretty typical.
I think it's
I've posted a draft release plan. It's not linked but can be found here:
http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
Since this is a transitional document, I'm not going to call for a vote
on it this morning, but will do so later, depending on how the comments
run.
for taking the time to respond to my mail, and more
power !
Best Regards,
Ted Husted wrote:
If there's a bottleneck, it would be the JSP tags.
Personally, I use Velocity Templates now, so the tags aren't an issue
for me. =:0)
JDR wrote:
Dear Ted:
Greetings ! I have
.
SuccessAction
would forward to the first forward that's defined for it.
This sounds like a great compromise, seeing as it would be totally
compatible with naming the forwards success, as well as anything else.
( I tend to use page in the analogous case).
Joe
--
Ted Husted,
Junit in Action - http
Just a head's up. I'd like to draw up a Release Plan tomorrow for Struts
1.2 beta 1. I'd like to get this out so people can start migrating to
the non-deprecated Struts 1.1+ (for lack of a better term) *before* we
get into the Commons Resources thing.
Since we did so much backward-compatiblity
There are 18 non-enhancement tickets in Bugzilla.
Paul, I tried to deploy the example
http://prdownloads.sourceforge.net/struts/pfexample.zip?download
under a fresh install of Tomcat 4.1.27 (full boat), but it loops
endlessly with these messages:
DEBUG [HostConfig[localhost]] (Digester.java:1255) - New
match='pageflow/flow/
downloaded it and tried it on Tomcat4.1 and Jboss 3. Paul T Smith
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]
Sent: Sunday, August 03, 2003 8:08 AM
To: Struts Developers List
Subject: Re: Workflow for Struts
Paul, I tried to deploy the example
The thing I keep coming back to is whether workflows are a Struts
problem. I would agree that multipage form *wizards* that collect input
are definitely a Struts problem. But, I can't but help wonder whether
more advanced types of workflows would be better defined as part of a
business
Steve Raeburn wrote:
SuccessAction does already exist in Scaffold. That version is slightly
different as it uses the Tokens constants class. I don't really see what
that would buy us, as the user would still need to know what name to enter
for the ActionForward. I wouldn't want to tie a core
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN
]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512.
-
To unsubscribe, e-mail
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec
201 - 300 of 1013 matches
Mail list logo
