What does Commons FileUpload being Filter-ized mean?
Jack
On Thu, 23 Dec 2004 08:37:24 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Wed, 22 Dec 2004 23:40:33 -0800, Don Brown [EMAIL PROTECTED] wrote:
The problem with putting code like that into a command, is what if
someone wants
On Thu, 23 Dec 2004 10:54:31 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
What does Commons FileUpload being Filter-ized mean?
Martin has talked (on the Commons dev list) about his plans to upgrade
Commons FileUpload to use a Servlet Filter, and the request wrapper
features of Servlet 2.3, in the
At 10:24 PM -0800 12/21/04, Don Brown wrote:
FWIW, so far, I extracted tiles and taglib into their own projects,
and got both core and taglib compiling (haven't tried tiles yet).
It took the steps I described earlier as well as moving some methods
from TagUtils back into ResponseUtils. Of
Joe Germuska wrote:
I do think that Struts shouldn't depend on subprojects.
-1.
core should not depdend on any subprojects I think. Not today, 1st day
or repackaging but eventualy.
I also think subprojects should be set up to depend on a struts.jar ...
and not the code.
--
RiA-SoA w/JDNC
At 6:09 AM -0600 12/22/04, Vic wrote:
Joe Germuska wrote:
I do think that Struts shouldn't depend on subprojects.
-1.
core should not depdend on any subprojects I think. Not today, 1st
day or repackaging but eventualy.
I also think subprojects should be set up to depend on a struts.jar
... and
--- Don Brown [EMAIL PROTECTED] wrote:
FWIW, so far, I extracted tiles and taglib into their own projects, and
got both core and taglib compiling (haven't tried tiles yet). It took
the steps I described earlier as well as moving some methods from
TagUtils back into ResponseUtils. Of
:) Actually, in the extraction I performed so far, I did just that and
moved TilesPreProcessor into the o.a.s.tiles.commands package. There
was one other class, o.a.s.actions.RedeployableActionServlet that I
moved into o.a.s.tiles since it was full of references to
TilesRequestProcessor.
On Tue, 21 Dec 2004 21:06:19 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown [EMAIL PROTECTED] wrote:
I agree as well. This lets us follow a consistent approach to
subprojects, where they may (and probably should) link to Struts core,
but
PROTECTED]
Sent: Tuesday, December 21, 2004 7:51 PM
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here
coming soon? Is that an offer? :) I like the API bean aka
ViewContext aka ConfigHelper and agree it is a better solution. Reading
over the API bean thread, Ted has convinced me this bean would actually
be created for each request probably somewhere early in the chain.
While it could be
.
Niall
- Original Message -
From: Don Brown [EMAIL PROTECTED]
To: Joe Germuska [EMAIL PROTECTED]
Cc: Struts Developers List dev@struts.apache.org
Sent: Wednesday, December 22, 2004 9:17 PM
Subject: Re: ViewUtils and UtilityFactory (was Extracting taglibs)
coming soon
and UtilityFactory (was Extracting taglibs)
coming soon? Is that an offer? :) I like the API bean aka
ViewContext aka ConfigHelper and agree it is a better solution. Reading
over the API bean thread, Ted has convinced me this bean would actually
be created for each request probably somewhere
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see happening to extract taglibs:
1. Move o.a.s.taglib out into its own subproject src tree
2.
PROTECTED]
Sent: Tuesday, December 21, 2004 7:51 PM
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here
, December 21, 2004 7:51 PM
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see
Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see happening to extract
taglibs:
1. Move o.a.s.taglib out
?
-Original Message-
From: Don Brown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 21, 2004 7:51 PM
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see happening to extract
taglibs
To: Struts Developers List
Subject: Extracting taglibs
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see happening to extract
taglibs:
1. Move
On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown [EMAIL PROTECTED] wrote:
I agree as well. This lets us follow a consistent approach to
subprojects, where they may (and probably should) link to Struts core,
but Struts core should not depend on them.
I hope this can actually be accomplished ...
This would be Tony the Tiger GRRREeattt!
Jack
On Tue, 21 Dec 2004 21:06:19 -0800, Craig McClanahan [EMAIL PROTECTED] wrote:
On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown [EMAIL PROTECTED] wrote:
I agree as well. This lets us follow a consistent approach to
subprojects, where
FWIW, so far, I extracted tiles and taglib into their own projects, and
got both core and taglib compiling (haven't tried tiles yet). It took
the steps I described earlier as well as moving some methods from
TagUtils back into ResponseUtils. Of course, if ResponseUtils has been
dreprecated
22 matches
Mail list logo
