[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affects 14 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - metro-reflector-blocks-complete : Avalon SVN - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://brutus.apache.org/gump/public/struts/struts-taglib/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts-taglib-11032005.jar] identifier set to project name -DEBUG- Dependency on jakarta-cactus-framework-12 exists, no need to add for property maven.jar.cactus-12. -DEBUG- Dependency on jakarta-cactus-integration-ant-12 exists, no need to add for property maven.jar.cactus-ant-12. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/struts/taglib/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/taglib/project.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html Work Name: build_struts_struts-taglib (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/struts/taglib] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/taglib/target/classes:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjrt.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjtools.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjweaver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-cactus/framework/dist-12/lib/cactus-11032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-11032005/checkstyle-11032005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-11032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11032005.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-11032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-11032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-11032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-11032005.jar:/usr/loc
[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affects 14 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - avalon-http-context : Avalon SVN - avalon-http-demo : Avalon SVN - avalon-http-examples : Avalon SVN - avalon-http-impl : Avalon SVN - avalon-http-server : Avalon SVN - avalon-http-servlet : Avalon SVN - avalon-http-static : Avalon SVN - avalon-http-test : Avalon SVN - avalon-planet-facilities : Avalon SVN - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - metro-reflector-blocks-complete : Avalon SVN - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://brutus.apache.org/gump/public/struts/struts-taglib/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts-taglib-11032005.jar] identifier set to project name -DEBUG- Dependency on jakarta-cactus-framework-12 exists, no need to add for property maven.jar.cactus-12. -DEBUG- Dependency on jakarta-cactus-integration-ant-12 exists, no need to add for property maven.jar.cactus-ant-12. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/struts/taglib/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/taglib/project.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html Work Name: build_struts_struts-taglib (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/struts/taglib] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/taglib/target/classes:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjrt.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjtools.jar:/usr/local/gump/packages/aspectj-1.2.1rc1/lib/aspectjweaver.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-cactus/framework/dist-12/lib/cactus-11032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-11032005/checkstyle-11032005.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-11032005.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-11032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11032005.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-11032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-11032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-11032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-11032005.jar:/usr/loc
Re: Storing current ActionContext in ThreadLocal
At 9:02 PM -0800 3/10/05, Martin Cooper wrote:
I would think we should just have the getter and setter in the
interface, and leave the actual thread-local part to the
implementation. Note that the getter and setter don't tie the impl to
the use of thread-locals, so if someone came up with an alternative
impl, that would be OK too.
Isn't the point of the ThreadLocal to make the ActionContext
statically reachable to a method which might be invoked without
having an instance passed to it?
public void pojoActionMethod() {
ActionContext ctx = ActionContext.currentInstance();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setForwardConfig(ctx.getMapping().findForward("b")); }
}
If we add the methods to the interface, then there's still no way to
pull yourself up by the bootstraps in a case like this.
As far as the actual impl of thread-local, I would think we could
define an abstract base class that does that part. Or does that negate
part of the reason for having ActionContext be an interface? (I
haven't been following along as closely as I should have been...)
There is the ActionContextBase abstract class, which would be a
suitable place to put it, except for the question of whether we want
to put it into the Interface as an instance method at all!
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: StrutsUpload
I gotta be honest with you, I've never used the upload capability in
Struts. I only needed upload functionality in one Struts app I wrote,
and it was an application that was originally using my old custom
framework that had its own way of doing uploads, so that just got ported
with the app. So, I'm starting from a point of ignorance with what
exists now.
This fact, coupled with what looks to me like a decent amount of code
posted, has made me glance over it a bit, but not try and absorb it in
any real detail. That's one of the reasons I made the comment about
comments: it would certainly help me understand what is going on and
what you are thinking throughout the code.
I think I can make one generic comment though... I would be talking to
the Struts team long before me :) If they aren't on board with this, to
me you are just wasting your time (as far as getting it in Struts goes
at least). They are in a better position to make intelligent comment
than I am anyway.
You might also consider a diagram or two, pictures being worth a
thousand words (or lines of code!) and all that... It might just be me
not knowing the current upload stuff, but a diagram or two might put a
lot of things in the proper context very quickly.
Again though, if the Struts team isn't behind this effort, I would
personally say the hell with it. Unless you want to release it
independent of them and Struts, it's probably wasted effort unfortunately.
Frank
Dakota Jack wrote:
Hello, Frank,
If you don't mind, I would like to talk to you a bit about what you
think is needed, so that I can be effective. Essentially the code is
an attempt to do two things:
1. Show how a slight change which can be made consistent with past
upload code in Struts can make life good for people who want to code
their own upload application.
2. Show how such an application might look, so that the idea of the
changes makes sense.
Part One (1) involves the first three interfaces which replace the
present code and provide interfaces the present code can live with. I
assume taht these interfaces are so obvious that comments are not too
necessary with them.
public interface MultipartFile
extends Serializable {
public longgetSize();
public voidsetSize(long fileSize);
public String getName();
public voidsetName(String fileName);
public String getContentType();
public voidsetContentType(String fileContentType);
public byte[] getData();
public InputStream getInputStream();
public voidreset();
}
public interface MultipartData {
public Iterator getParameterNames();
public String getParameter(String name);
public String[] getParameterValues(String name);
public Map getFiles();
}
public interface MultipartHandler {
public void handleRequest(Object [] params) throws IOException;
public ActionMapping getMapping();
public void setMapping(ActionMapping mapping);
public ActionServlet getServlet();
public void setServlet(ActionServlet servlet);
}
The first part of the Second Part (2) is more complicated, but the
only classes of any import are just implementations of the rather
obvious interfaces. The second part of the Second Part (2) is much
more complicated and cannot really be understood without the rest of
the application. This is not too important except for showing how an
Upload class that acts as the glue between the upload application and
the Struts framework might look. I want access to ActionForm so that
I can use the ActionForm in the application that feeds the Upload
class and so that Monitor subclasses can have a framework basis to
return data too.
Given this, what do you think would be helpful to you? Keep it in
mind that my goal is not to focus on the applicatoin at present but on
the proposed opening up of the Struts framework. I can code this on
my own and use it, but I would rather it were possible for others to
also provide sample applicatoins.
Is this helpful?
Jack
On Fri, 11 Mar 2005 00:25:41 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
Jack, one comment on this... I think it would be helpful to comment the
code you've posted.
Frank
dev@struts.apache.org wrote:
Date: 2005-03-10T21:20:10
Editor: DakotaJack
Wiki: Apache Struts Wiki
Page: StrutsUpload
URL: http://wiki.apache.org/struts/StrutsUpload
no comment
Change Log:
--
@@ -70,10 +70,13 @@
3. !UploadFileItemFactory (extends
org.apache.commons.fileupload.!DefaultFileItemFactory)
4. Monitor
5. Upload
+ 6. !UploadParams
== Code ==
-=== MultipartFile ===
+=== Framework Code ===
+
+ MultipartFile
{{{
public interface MultipartFile
@@ -90,7 +93,7 @@
}
}}}
-=== MultipartData ===
+ MultipartData
{{{
public interface MultipartData {
@@ -101,7 +104,7 @@
}
}}}
-=== MultipartHandler ===
+ MultipartHandler
{{{
public interface Multipar
Re: [Apache Struts Wiki] New: BuildingShale
I´ve had problems with proxy when checking out the modules (report of
... 400 bad request). But the problem was fixed when i changed the url
to https://svn.apache.org/repos/asf/struts/shale/trunk/ (using ssl).
Maybe it´s good to add this to the document. Well, I know that
explaining the use of svn is not the point, but ...
til next time,
__
Eugênio Saulo
dev@struts.apache.org wrote:
Date: 2005-03-05T10:15:41
Editor: DuncanMills
Wiki: Apache Struts Wiki
Page: BuildingShale
URL: http://wiki.apache.org/struts/BuildingShale
no comment
New Page:
= Building Shale =
This page describes wrinkles in building Shale from source for (hopefully)
various IDEs
== JDeveloper 10.1.3 ==
To get the Ant compile to run successfully in JDeveloper a couple of changes have to be made to the build.xml ''if'' you want to use the JSF RI as shipped with JDeveloper and the OC4J servlet API JARs rather than downloading a separate JSF RI and Tomcat just to keep the build script happy.
This assumes the use of JDeveloper 10.1.3 developer preview (J2EE edition)
=== build.properties ===
* The JSF RI jars are in {jdev-home}/jsf-ri
* The servet and JSP API jars are in {jdev-home}/j2ee/home/lib
=== build.xml ===
A few property changes to make here:
* Change '''jsf-api.jar''' to use ''${jsf.home}/jsf-api.jar'' rather than
${jsf.home}/lib/jsf-api.jar
* Change '''jsf-impl.jar''' to use ''${jsf.home}/jsf-impl.jar'' rather than
${jsf.home}/lib/jsf-impl.jar
* Change '''jsp-api.jar''' to use ''${server.home}/ojsp.jar'' rather than
${server.home}/common/lib/jsp-api.jar
* Change '''servlet-api.jar''' to use ''${server.home}/servlet.jar'' rather
than ${server.home}/common/lib/servlet-api.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Storing current ActionContext in ThreadLocal
What about using a different class to host the ThreadLocal?
public void pojoActionMethod() {
ActionContext ctx = ActionContextHolder.getActionContext();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setForwardConfig(ctx.getMapping().findForward("b")); }
}
The instance would be set by the RequestProcessor at the start of the
chain after the context is created.
Hubert
On Fri, 11 Mar 2005 05:48:43 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 9:02 PM -0800 3/10/05, Martin Cooper wrote:
> >I would think we should just have the getter and setter in the
> >interface, and leave the actual thread-local part to the
> >implementation. Note that the getter and setter don't tie the impl to
> >the use of thread-locals, so if someone came up with an alternative
> >impl, that would be OK too.
>
> Isn't the point of the ThreadLocal to make the ActionContext
> statically reachable to a method which might be invoked without
> having an instance passed to it?
>
> public void pojoActionMethod() {
>
> ActionContext ctx = ActionContext.currentInstance();
> if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
> else { ctx.setForwardConfig(ctx.getMapping().findForward("b")); }
> }
>
> If we add the methods to the interface, then there's still no way to
> pull yourself up by the bootstraps in a case like this.
>
> >As far as the actual impl of thread-local, I would think we could
> >define an abstract base class that does that part. Or does that negate
> >part of the reason for having ActionContext be an interface? (I
> >haven't been following along as closely as I should have been...)
>
> There is the ActionContextBase abstract class, which would be a
> suitable place to put it, except for the question of whether we want
> to put it into the Interface as an instance method at all!
>
> Joe
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: StrutsUpload
Thanks, Frank. I posted this code in response to Ted's suggestion that this is the way to go to establish a dialogue with the committers on code. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Struts Wiki] Updated: StrutsUpload
Date: 2005-03-11T09:10:32
Editor: DakotaJack
Wiki: Apache Struts Wiki
Page: StrutsUpload
URL: http://wiki.apache.org/struts/StrutsUpload
no comment
Change Log:
--
@@ -1,78 +1,14 @@
== Overview ==
-Utilizing the sort of structure suggested for Struts upload below allows us to
have an !ActionUpload class as follows:
+Presently the Struts code does the following: (1) wrap the request in a
multipart request that has to be continually unwrapped prior to use and prior
to being initialized anyway; (2) parse the request inside the population of the
!ActionForm, i.e. in !RequestUtils.
-(This is actual code used in a working application online.)
+This is excellent, since the deferment of anything substantial until
!RequestUtils allows the Struts Team, should you choose to take this
assignment, the opportunity to make Struts v1.3 accessible to people wanting to
build upload applications.
-{{{
-public class UploadAction
-extends Action {
- public ActionForward execute(ActionMapping mapping,
- ActionForm form,
- HttpServletRequest req,
- HttpServletResponse res)
- throws Exception {
-HttpSessionsess = req.getSession();
-Upload upload = (Upload)sess.getAttribute(UploadConstant.UPLOAD);
-if(upload == null) {
- upload = new Upload();
- sess.setAttribute(UploadConstant.UPLOAD,upload);
-}
-if(upload.isMultipart(req)) {
- Monitor progress =
(UploadMonitorProgress)sess.getAttribute(UploadConstant.MONITOR);
- if(progress == null) {
-progress = new UploadMonitorProgress();
-sess.setAttribute(UploadConstant.MONITOR,progress);
- }
- List monitors = Collections.synchronizedList(new LinkedList());
- intsize = UploadConstant.MAX_FILE_SIZE;
- inttype = UploadConstant.DIR;
- String path = LoadFileUtil.getUploadPath(type,user.getId());
- String temp = LoadFileUtil.UPLOAD_TEMP_FILES;
- String code = UploadConstant.DEFAULT_ENCODING;
- monitors.add(progress);
- upload.process(req,monitors,code,size);
- upload.store(type, path, temp);
- sess.setAttribute(UploadConstant.REPORT,UploadReport.getReport(upload));
-}
-return new ActionForward(...);;
- }
-}
-}}}
+As things stand, you have to change Struts to build an upload application with
any sophistication. Making Struts more flexible is rather easy. Just use the
following three interfaces.
-The point of this presentation is not the classes given. The point is that I
am would hope that the committers working on the Struts multipart processing
would make some attempt to provide a basis for applications other than the
Struts upload package. These classes are not meant to be that basis, other
than the so-called "Framework Code" given below.
+An example of how someone might want to use these interfaces is also given
following the interfaces.
-This is about Struts v1.2.6 and forward multipart requests. The first four
classes/interfaces are suggested as a basis for allowing Struts
users/developers to implement their own file upload applications. The object
of suggesting these classes is to make the use of !ActionForm available to
users/developers who want to do something more than the present default file
upload application packaged with Struts allows but maintaining backward
compatibility. I assume that those committers working on the upload package
can see how these classes could be seemlessly applied to Struts without
disturbing expectations of prior users.
-
-The last three classes following the four main classes are example
implementations of the first three interfaces and the !MultipartUtil. Any
comments or suggestions are welcomed.
-
-After the seven classes a few classes to indicate what sorts of
applications/implementations the seven classes would make possible are
provided. All the classes following the first four classes are not meant to be
part of the framework. If the example class Upload is studied, you will see
that this class is totally ignorant of the view or the data coming from the
multipart form. This is good. You will also see that, if the first four
classes were part of the framework, the Upload class would also be totally
ignorant of the request. This would be idea. As things stand, since
non-Struts upload applications have no access to the !ActionForm, the Upload
application has to have some hook to the framework to get the data for the
view. This is what ideally we would like to avoid.
-
-I do use this application and others like it, but the point here is to see the
flexibility that classes like the first four classes can give us. The
important classes, the first three, are interfaces with "eXtremely" (pun
intended) generic methods. Please note how eas
Re: [Apache Struts Wiki] Updated: StrutsUpload
I'm not sure how many of the committers relish the idea of reading through about 1,000 lines of completely uncommented code and trying to understand what it all means. And that on a wiki page, rather than in their favourite editor where they would have syntax colouring and could jump around at will, from definition to usage, etc., to help understand it. Add to that almost 40 updates to the wiki page in the last 10 days, and there's even less incentive to start looking at it, fully expecting a flurry of updates before they've got much beyond the first paragraph. I would suggest that you finish your work on it first, then put the code somewhere that people can download and bring up in their editor, and have a wiki page that explains what you're trying to do and that points to the code download. That's much more likely to get people looking at it, at least in my opinion. -- Martin Cooper On Fri, 11 Mar 2005 08:29:19 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Thanks, Frank. I posted this code in response to Ted's suggestion > that this is the way to go to establish a dialogue with the committers > on code. > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Storing current ActionContext in ThreadLocal
At 10:08 AM -0600 3/11/05, Hubert Rabago wrote:
What about using a different class to host the ThreadLocal?
public void pojoActionMethod() {
ActionContext ctx = ActionContextHolder.getActionContext();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setForwardConfig(ctx.getMapping().findForward("b")); }
}
It seems arbitrary to me, and more of a burden than simply having a
public static ThreadLocal which most people would ignore -- but if
others prefer this approach, I wouldn't fight it.
The instance would be set by the RequestProcessor at the start of the
chain after the context is created.
Yes, no matter where we store the ActionContext, my intent would be
to set this in process() right after contextInstance(...).
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: StrutsUpload
Thanks, Martin, but I think that your suggestion is not related to what I am trying to do. I have gotten rid of code in the last formulation to make this clear. Only the first three interfaces are really important and nothing has changed in those ever. What I am suggesting is using those interfaces so that alternative applications can be used. The particular application provided is just to show that it can be done and is done. So, the changes are irrelevant to what I am suggesting. I won't change it anymore. The first day this code was presented is as sufficient as today. I only made changes in hopes of getting some response. It is ironic that it has had the opposite affect. You probably are the only one relevant to this anyway, and I assumed that you would get this straight-off, as I am sure you have? Jack On Fri, 11 Mar 2005 09:15:51 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > I'm not sure how many of the committers relish the idea of reading > through about 1,000 lines of completely uncommented code and trying to > understand what it all means. And that on a wiki page, rather than in > their favourite editor where they would have syntax colouring and > could jump around at will, from definition to usage, etc., to help > understand it. Add to that almost 40 updates to the wiki page in the > last 10 days, and there's even less incentive to start looking at it, > fully expecting a flurry of updates before they've got much beyond the > first paragraph. > > I would suggest that you finish your work on it first, then put the > code somewhere that people can download and bring up in their editor, > and have a wiki page that explains what you're trying to do and that > points to the code download. That's much more likely to get people > looking at it, at least in my opinion. > > -- > Martin Cooper > > > On Fri, 11 Mar 2005 08:29:19 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > Thanks, Frank. I posted this code in response to Ted's suggestion > > that this is the way to go to establish a dialogue with the committers > > on code. > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its back." > > ~Dakota Jack~ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] Updated: StrutsUpload
There are, in other words, only about 15 lines of code that are
relevant: here they are:
1.1.1. MultipartFile
public interface MultipartFile
extends Serializable {
public longgetSize();
public voidsetSize(long fileSize);
public String getName();
public voidsetName(String fileName);
public String getContentType();
public voidsetContentType(String fileContentType);
public byte[] getData();
public InputStream getInputStream();
public voidreset();
}
1.1.2. MultipartData
public interface MultipartData {
public Iterator getParameterNames();
public String getParameter(String name);
public String[] getParameterValues(String name);
public Map getFiles();
}
1.1.3. MultipartHandler
public interface MultipartHandler {
public void handleRequest(Object [] params) throws IOException;
public ActionMapping getMapping();
public void setMapping(ActionMapping mapping);
public ActionServlet getServlet();
public void setServlet(ActionServlet servlet);
}
On Fri, 11 Mar 2005 09:38:00 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Thanks, Martin, but I think that your suggestion is not related to
> what I am trying to do.
>
> I have gotten rid of code in the last formulation to make this clear.
>
> Only the first three interfaces are really important and nothing has
> changed in those ever. What I am suggesting is using those interfaces
> so that alternative applications can be used.
>
> The particular application provided is just to show that it can be
> done and is done. So, the changes are irrelevant to what I am
> suggesting.
>
> I won't change it anymore.
>
> The first day this code was presented is as sufficient as today.
>
> I only made changes in hopes of getting some response. It is ironic
> that it has had the opposite affect.
>
> You probably are the only one relevant to this anyway, and I assumed
> that you would get this straight-off, as I am sure you have?
>
> Jack
>
>
> On Fri, 11 Mar 2005 09:15:51 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > I'm not sure how many of the committers relish the idea of reading
> > through about 1,000 lines of completely uncommented code and trying to
> > understand what it all means. And that on a wiki page, rather than in
> > their favourite editor where they would have syntax colouring and
> > could jump around at will, from definition to usage, etc., to help
> > understand it. Add to that almost 40 updates to the wiki page in the
> > last 10 days, and there's even less incentive to start looking at it,
> > fully expecting a flurry of updates before they've got much beyond the
> > first paragraph.
> >
> > I would suggest that you finish your work on it first, then put the
> > code somewhere that people can download and bring up in their editor,
> > and have a wiki page that explains what you're trying to do and that
> > points to the code download. That's much more likely to get people
> > looking at it, at least in my opinion.
> >
> > --
> > Martin Cooper
> >
> >
> > On Fri, 11 Mar 2005 08:29:19 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > Thanks, Frank. I posted this code in response to Ted's suggestion
> > > that this is the way to go to establish a dialogue with the committers
> > > on code.
> > >
> > >
> > > --
> > > "You can lead a horse to water but you cannot make it float on its back."
> > > ~Dakota Jack~
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Apache Struts Wiki] New: BuildingShale
Fair enough Eugênio send me details directly and I'll be happy to put a
note into the Wiki - or you can register and do it yourself :-)
Duncan
Eugênio Saulo wrote:
I´ve had problems with proxy when checking out the modules (report of
... 400 bad request). But the problem was fixed when i changed the url
to https://svn.apache.org/repos/asf/struts/shale/trunk/ (using ssl).
Maybe it´s good to add this to the document. Well, I know that
explaining the use of svn is not the point, but ...
til next time,
__
Eugênio Saulo
dev@struts.apache.org wrote:
Date: 2005-03-05T10:15:41
Editor: DuncanMills
Wiki: Apache Struts Wiki
Page: BuildingShale
URL: http://wiki.apache.org/struts/BuildingShale
no comment
New Page:
= Building Shale =
This page describes wrinkles in building Shale from source for
(hopefully) various IDEs
== JDeveloper 10.1.3 ==
To get the Ant compile to run successfully in JDeveloper a couple of
changes have to be made to the build.xml ''if'' you want to use the
JSF RI as shipped with JDeveloper and the OC4J servlet API JARs
rather than downloading a separate JSF RI and Tomcat just to keep the
build script happy. This assumes the use of JDeveloper 10.1.3
developer preview (J2EE edition)
=== build.properties ===
* The JSF RI jars are in {jdev-home}/jsf-ri
* The servet and JSP API jars are in {jdev-home}/j2ee/home/lib
=== build.xml ===
A few property changes to make here:
* Change '''jsf-api.jar''' to use ''${jsf.home}/jsf-api.jar'' rather
than ${jsf.home}/lib/jsf-api.jar
* Change '''jsf-impl.jar''' to use ''${jsf.home}/jsf-impl.jar''
rather than ${jsf.home}/lib/jsf-impl.jar
* Change '''jsp-api.jar''' to use ''${server.home}/ojsp.jar'' rather
than ${server.home}/common/lib/jsp-api.jar
* Change '''servlet-api.jar''' to use ''${server.home}/servlet.jar''
rather than ${server.home}/common/lib/servlet-api.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
At 8:29 AM -0800 3/11/05, Dakota Jack wrote: Thanks, Frank. I posted this code in response to Ted's suggestion that this is the way to go to establish a dialogue with the committers on code. I would totally endorse Ted's suggestion. The best approach is to publicly document approaches and, where possible, provide extension code that can be exercised without rushing a change to the Struts core. This is how struts-chain was developed and verified as a reasonable approach before the core was changed. It also happens to be how validator and tiles evolved. In a much more modest fashion, this was the origin of the DigestingPlugIn, which I developed and published and which was adopted into Struts all before I was a committer. I feel bad seeing Frank's obvious bitter feelings, and as I noted elsewhere, I'm sorry I wasn't following the thread closely enough to warn that his efforts were pushing in a direction that Struts doesn't follow. In fact, I know of no open source project which would add incompatible features to an older release, except in the case of a major version number change. I don't think we've earned "Struts 2.0" with the other changes we have, although until we do a release, we could certainly debate calling the chain based processor Struts 2.0 and making room for Frank's changes in what would then be a live development version on the 1.x branch. As always, remember that we're all volunteers here, and we all have to scrounge for the time we apply to Struts. Also, we have an enormous installed base, and we have to take their needs into account. If the general open source community has come to expect compatibility between minor version releases, and if we've always struck a firm stance towards providing that kind of compatibility in Struts, then we need to maintain consistency. Frank, have you exhausted any hope of packaging your changes as something which can be added on to Struts 1.2 without requiring changes to the core classes? It may seem cumbersome, but I have a feeling that it would be possible to package your changes as extensions instead of core changes or a forked Struts distribution. Where Struts falls short in this regard, I would be interested in helping design and implement changes to both 1.2 and 1.3 to improve its extensibility. If Frank is burned out, but there's as much interest as there seemed to be on the list, perhaps some of those people would be willing to carry the baton to the next stage. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 8:29 AM -0800 3/11/05, Dakota Jack wrote: > >Thanks, Frank. I posted this code in response to Ted's suggestion > >that this is the way to go to establish a dialogue with the committers > >on code. > > I would totally endorse Ted's suggestion. We will see if it works. I did that. I have made a proposal which can be assessed at this stage. There is no question about what would need to be done to implement the code I have provided. The basis is, as I said, about 15 lines of code. The idea is what is what must be accepted or rejected. I don't have time to spin my wheels. If the idea is not acceptable no matter what, then that is okay. But, if that is the case, doing "no matter what" is spinning wheels. > The best approach is to > publicly document approaches and, where possible, provide extension > code that can be exercised without rushing a change to the Struts > core. This is how struts-chain was developed and verified as a > reasonable approach before the core was changed. It also happens to > be how validator and tiles evolved. In a much more modest fashion, > this was the origin of the DigestingPlugIn, which I developed and > published and which was adopted into Struts all before I was a > committer. I am not sure what this means in terms of what I discussed and provided. I am not suggesting a change to the Struts core. I am not even suggesting something inconsistent with present practice. > In fact, I know of no open source project which would add > incompatible features to an older release, except in the case of a > major version number change. Isn't branching common? I may misunderstand this? > I don't think we've earned "Struts 2.0" with the other changes we > have, although until we do a release, we could certainly debate > calling the chain based processor Struts 2.0 and making room for > Frank's changes in what would then be a live development version on > the 1.x branch. If this is just an opening of the RequestProcessor logic, why is it discussed so much as "chain based"? Shouldn't the interface allow for changes in the future which are not chain based? There is so little discussion about core changes on this list that what is happening is impossible to tell unless you are one of the few people doing all the work. The options from someone on the "outside" seem to be to have ten people doing ten things on their own and then submitting it all at one time to see who wins, rather than working together. I thought I could work with people on a list like this. Is that not the idea? This seems to be impossible from my perspective. No matter what you provide, it is always met with "we cannot comment on that at this time because " or "no". It is frustrating, Martin. > As always, remember that we're all volunteers here, and we all have > to scrounge for the time we apply to Struts. Also, we have an > enormous installed base, and we have to take their needs into > account. If the general open source community has come to expect > compatibility between minor version releases, and if we've always > struck a firm stance towards providing that kind of compatibility in > Struts, then we need to maintain consistency. I think we all know that. I really do. Somehow there is this idea that this basic requirement escapes people. But, I don't think it does. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Hi Joe, I'm not burnt out at this point, and I wouldn't even say bitter. I may have been initially, I am human and so react with emotion, same as anyone. A more objective review of the situation in the intervening time though has lead me to a place where I am a bit frustrated by my inability to not achieve the results I hoped for, but I'm not bitter or angry. As you said, there did seem to be a lot of support for an idea along the lines of what I did, so it seemed like something that should have garnered more discussion and perhaps alternative proposals. That didn't happen though, and while the reasons may have been perfectly valid, it is still frustrating to an "outsider", as Jack put it :) I am still very much interested in putting the time in, and I would be more than happy to explore alternative ways of doing what I proposed. I am open to suggestion!! To be honest, I haven't thought much about ways this might be done as an "extension" to Struts... I'm not sure I see a good way that would result in the same functionality in the same way (which I believe to be a good approach, and many would seem to agree). I am listening though! :) However, I am not right now willing to put in time on something to demonstrate an idea or something that *might" be accepted. If we can all come to some concensus on how to proceed (that I agree with) then I would absolutely love to do the work. I am not willing to waste my time though, as I'm sure no one is. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Joe Germuska wrote: At 8:29 AM -0800 3/11/05, Dakota Jack wrote: Thanks, Frank. I posted this code in response to Ted's suggestion that this is the way to go to establish a dialogue with the committers on code. I would totally endorse Ted's suggestion. The best approach is to publicly document approaches and, where possible, provide extension code that can be exercised without rushing a change to the Struts core. This is how struts-chain was developed and verified as a reasonable approach before the core was changed. It also happens to be how validator and tiles evolved. In a much more modest fashion, this was the origin of the DigestingPlugIn, which I developed and published and which was adopted into Struts all before I was a committer. I feel bad seeing Frank's obvious bitter feelings, and as I noted elsewhere, I'm sorry I wasn't following the thread closely enough to warn that his efforts were pushing in a direction that Struts doesn't follow. In fact, I know of no open source project which would add incompatible features to an older release, except in the case of a major version number change. I don't think we've earned "Struts 2.0" with the other changes we have, although until we do a release, we could certainly debate calling the chain based processor Struts 2.0 and making room for Frank's changes in what would then be a live development version on the 1.x branch. As always, remember that we're all volunteers here, and we all have to scrounge for the time we apply to Struts. Also, we have an enormous installed base, and we have to take their needs into account. If the general open source community has come to expect compatibility between minor version releases, and if we've always struck a firm stance towards providing that kind of compatibility in Struts, then we need to maintain consistency. Frank, have you exhausted any hope of packaging your changes as something which can be added on to Struts 1.2 without requiring changes to the core classes? It may seem cumbersome, but I have a feeling that it would be possible to package your changes as extensions instead of core changes or a forked Struts distribution. Where Struts falls short in this regard, I would be interested in helping design and implement changes to both 1.2 and 1.3 to improve its extensibility. If Frank is burned out, but there's as much interest as there seemed to be on the list, perhaps some of those people would be willing to carry the baton to the next stage. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
I feel that Jack is on to something important here... the ability for "outsiders" to work on Struts seems to me an almost impossible task. We are constantly told "make a proposal", "put it up in the Wiki" or "open a ticket with your suggestions", but the problem with that is that we are spending a lot of time doing things that can be rejected out-of-hand for any reason by any members of the PMC. Also, we don't know what you guys are cooking up many times, as evidenced by the addition (I believe it was Martin) made a night or two ago that was along the lines of what I had done but for the 1.3 branch... it seems like my work prompted him to do something similar, and because he could simply do it and add it without any discussion, he "beats me to the punch", in essence. Plus, this was without any discussion that I saw (I apologize if I missed it) on the public lists. How is someone like me or Jack that wants to get involved supposed to do so under those conditions? Why would we *ever* put the time in without knowing (a) whether it will be accepted or not and (b) that one of the Struts team won't just go do it themselves? As Ted correctly says, we're all volunteers, but the difference is that you guys know your contributions aren't a waste of time (mostly... I realize other members can veto your additions). We don't have the luxury of that knowledge before we put the time in. You know, I made a proposal a week or two ago to develop a site that would track enhancements being worked on, who was doing it, etc. I offered to do the site development work and even host it. It was rejected for various reasons. I still believe something along those lines would go a long way to helping alleviate this problem, and no, I still do not agree that the Wiki and/or Bugzilla serves this purpose. I seemed to be the only one with that opinion though. The point being, whether this idea or not, I believe *something* needs to be done because there are people willing to participate that see a very high barrier to entry, one that seems to be next to impossible to get around. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: At 8:29 AM -0800 3/11/05, Dakota Jack wrote: Thanks, Frank. I posted this code in response to Ted's suggestion that this is the way to go to establish a dialogue with the committers on code. I would totally endorse Ted's suggestion. We will see if it works. I did that. I have made a proposal which can be assessed at this stage. There is no question about what would need to be done to implement the code I have provided. The basis is, as I said, about 15 lines of code. The idea is what is what must be accepted or rejected. I don't have time to spin my wheels. If the idea is not acceptable no matter what, then that is okay. But, if that is the case, doing "no matter what" is spinning wheels. The best approach is to publicly document approaches and, where possible, provide extension code that can be exercised without rushing a change to the Struts core. This is how struts-chain was developed and verified as a reasonable approach before the core was changed. It also happens to be how validator and tiles evolved. In a much more modest fashion, this was the origin of the DigestingPlugIn, which I developed and published and which was adopted into Struts all before I was a committer. I am not sure what this means in terms of what I discussed and provided. I am not suggesting a change to the Struts core. I am not even suggesting something inconsistent with present practice. In fact, I know of no open source project which would add incompatible features to an older release, except in the case of a major version number change. Isn't branching common? I may misunderstand this? I don't think we've earned "Struts 2.0" with the other changes we have, although until we do a release, we could certainly debate calling the chain based processor Struts 2.0 and making room for Frank's changes in what would then be a live development version on the 1.x branch. If this is just an opening of the RequestProcessor logic, why is it discussed so much as "chain based"? Shouldn't the interface allow for changes in the future which are not chain based? There is so little discussion about core changes on this list that what is happening is impossible to tell unless you are one of the few people doing all the work. The options from someone on the "outside" seem to be to have ten people doing ten things on their own and then submitting it all at one time to see who wins, rather than working together. I thought I could work with people on a list like this. Is that not the idea? This seems to be impossible from my perspective. No matter what you provide, it is always met with "we cannot comment on that at this time because " or "no".
[Apache Struts Wiki] Updated: LocalSpellingWords
Date: 2005-03-11T11:44:06 Editor: 64.105.251.26 Wiki: Apache Struts Wiki Page: LocalSpellingWords URL: http://wiki.apache.org/struts/LocalSpellingWords no comment Change Log: -- @@ -100,3 +100,5 @@ walls com decapitalize docs Introspector java javabeans + +Feb jakarta Javadocs roadmap - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
I couldn't find it in the archives, but I did find it in my own trash
folder...
It was actually from Joe, in reply to Hubert, as part of the discussion
about what I was doing. As I said, it's not exactly what I did, but it
is very much along the same lines, except that it's for the 1.3 branch,
and is per-forward only. Here's the message:
Hubert wrote:
And I've been silently wishing you'd add it, too. :)
We've had discussions about this maybe twice before, and another time
I lit the flame, you responded, but I wasn't able to follow through
with the discussion.
Joe wrote:
Well, then, now you've gone and done it, Hubert... I've just committed the
basic support for per-forward commands.
I think the next step would be to write a simple command which looks something
like this:
public class FormPrepCommand implements Command {
private String formName; // property
private String formScope; // property
public boolean execute(Context context) {
if (this.formName != null) {
ActionContext actionCtx = (ActionContext) context;
ActionForm form = lookupForm(formName,formScope, actionCtx);
prepareForm(actionCtx, form);
return false;
}
}
protected ActionForm lookupForm(String formName, String formScope,
ActionContext ctx) {
// standard behavior for looking up a form and making sure its in the right
request/session scope
// classes would rarely override this; maybe it would be private.
}
protected abstract void prepareForm(ActionContext ctx, ActionForm form);
}
Then one could use one or more of these in a per-forward chain of renders.
Of course other commands could do non-form oriented setup.
Related to what I just checked in, I still like a model where rather than configuring command and
catalog on each ForwardConfig, a lookup is done based on the "path" value of the
ForwardConfig. No reason not to have both, of course, but I just think my style would be to have a
catalog named "page-prep" and a different command in process-view which worked this way.
Joe
Frank W. Zammetti wrote:
Fair enough, I wasn't certain. :)
I'm trying to find the relevant message now so as to not be posting FUD
by mistake!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Also, we don't know what you guys are cooking up many times, as evidenced by the addition (I believe it was Martin) made a night or two ago that was along the lines of what I had done but for the 1.3 branch... it seems like my work prompted him to do something similar, and because he could simply do it and add it without any discussion, he "beats me to the punch", in essence. Plus, this was without any discussion that I saw (I apologize if I missed it) on the public lists. How is someone like me or Jack that wants to get involved supposed to do so under those conditions? Why would we *ever* put the time in without knowing (a) whether it will be accepted or not and (b) that one of the Struts team won't just go do it themselves? Well, that was me, actually. And there had been lots of prior discussion, as cited by Hubert in three URLs in a message which motivated me to finally do it. That prior discussion dates back more than a year. But no, I didn't beat you to the punch, if you feel that a solution is necessary which works with Struts 1.2 without using struts-chain. As Ted correctly says, we're all volunteers, but the difference is that you guys know your contributions aren't a waste of time (mostly... I realize other members can veto your additions). We don't have the luxury of that knowledge before we put the time in. But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef project. Or AppFuse. These are all things which help people use Struts. There are others. You know, I made a proposal a week or two ago to develop a site that would track enhancements being worked on, who was doing it, etc. I offered to do the site development work and even host it. It was rejected for various reasons. I still believe something along those lines would go a long way to helping alleviate this problem, and no, I still do not agree that the Wiki and/or Bugzilla serves this purpose. I remember the proposal, although I don't remember how it was meant to stay accurate and up to date. To be honest (and hopefully not appearing rude), I don't see how having this site would help me have the time to put stuff there, or anyone else who is working on various features. I'm not meaning this email to be the final word, or to imply that there the problems you raise are immaterial, but I think those problems are inherent to a community like ours, made up of a bunch of distributed volunteers. I don't even have the bandwidth I'd like to cut code and participate in all of the discussions on the Struts lists, let alone having extra bandwidth for community engineering. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Joe Germuska wrote: Well, that was me, actually. And there had been lots of prior discussion, as cited by Hubert in three URLs in a message which motivated me to finally do it. That prior discussion dates back more than a year. Yep, I found it in my trash folder. Sorry for the confusion! :) It's fair that there was discussion, but an obvious problem is still apparent... I've only been on the lists for a couple of months. I would certainly think no one expects a person to go through the entire list archives to catch up :) I think we really need something that cuts through the "noise" on the list, meaning that we have a repository where the discussions on the list are boiled down to actual action points for people to reference. This is kind of basic project management stuff I'm talking about. You debate in a meeting, then someone draws up a list of what is being done by who, *referencing* the discussion thread if it is needed. I don't see where we have anything like that at this point. I don't believe the Wiki nor Bugzilla is it. But no, I didn't beat you to the punch, if you feel that a solution is necessary which works with Struts 1.2 without using struts-chain. That's true, but only to a point... since I've now been told that "no new features will ever be added to anything but 1.3 and beyond", there is no hope of my work ever being incorporated into the core *if* a different direction is used in 1.3. Therefore, in a sense you *did* beat me to the punch because there was no chance for me to explore doing it in 1.3 Now, you could say that was my fault for not starting my work with 1.3, and I couldn't really argue that :) But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef project. Or AppFuse. These are all things which help people use Struts. There are others. Your right of course, and like I said, if there is a way to do this as an extension to the framework, and especially if someone wants to suggest such an option, I am willing to listen and do the work. I will explore some possible approaches on my own. But I still feel this is something that *should* in fact be in the core. I don't think anyone is going to change my mind on that point. Unfortunately, if I can't convince any of you, then it's just an opinion, and everyones' got one :) I remember the proposal, although I don't remember how it was meant to stay accurate and up to date. The part where I saw my proposal really differing from the Wiki or Bugzilla (and in that way be more accurate and up-to-date) is that in an automated fashion it would "tickle" for status the assignee of a particular enhancement (note that I only intended for it to cover enhancements). In other words... (1) You go to the site and see an enhancement proposal that interests you (I could imagine a list of requested/suggested enhancements and a separate list of what is actually being done). No one else has stepped forward to work on it, so you volunteer. That task is then assigned to you. (2) At some regular interval (every week?) an automated message goes out to you asking for an update on your progress. If no response is received within some time period (48 hours?), then that task is unassigned, and someone else can pick it up. In this way, we would always know who is working on what, and at least a rough idea of their progress. True, they could just do a quick "I'm working on it" update every week, but one has to assume some level of commitment to at least write brief *real* update of they were interested to volunteer in the first place. If someone drops something, someone else can pick it up. In many ways its just a slightly more automated version of what exists now, but I think it would make a big difference, There is more that could be done of course, but this was the starting point I suggested and offered to build. To be honest (and hopefully not appearing rude), I don't see how having this site would help me have the time to put stuff there, or anyone else who is working on various features. Not appearing rude at all because clearly it wouldn't :) But someone could at least know that what they are working on isn't being done by someone else concurrently. At least you wouldn't find out that all your hard work was already done by someone else, and they released before you. Also, we could allow for things like multiple assignees, so that if two people had a competing approach to something, we'd know it and both would know that their solution may not be choosen. At least they could know that up-front instead of only after they did the wasted work. I'm not meaning this email to be the final word, or to imply that there the problems you raise are immaterial, but I think those problems are inherent to a community like ours, made up of a bunch of distributed volunteers. I don't even have the bandwidth I'd like to cut code and participate in all of the discussions on the Str
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Hi Frank,
I've been participating in discussions about the feature you proposed
since last year, and I've been looking to participate in its inclusion
into Struts.
> As you said, there did seem to be a lot of support for an idea along the
> lines of what I did, so it seemed like something that should have
> garnered more discussion and perhaps alternative proposals.
Joe most recently mention this sometime last month:
http://marc.theaimsgroup.com/?l=struts-dev&m=110842402707799&w=2
Aside from this, an email I sent to you (well, on the user list, but
on the thread where you mentioned this) also linked to a couple of
threads discussing this feature. That mentioned a few alternatives,
including one from me. I even noted that the message was almost a
year old. :)
http://marc.theaimsgroup.com/?l=struts-user&m=111029587900454&w=2
> I am still very much interested in putting the time in, and I would be
> more than happy to explore alternative ways of doing what I proposed. I
> am open to suggestion!! To be honest, I haven't thought much about ways
> this might be done as an "extension" to Struts... I'm not sure I see a
> good way that would result in the same functionality in the same way
> (which I believe to be a good approach, and many would seem to agree).
> I am listening though! :)
The 1.3 support includes a change to the config DTD. A 1.2 friendly
change could look something like:
package.SpecificSetupActionForward would either extend a
SetupActionForward, or implement a SetupActionForward. In either
case, a setupView() method would be implemented/overridden.
The action's return could look like:
return ViewSetupUtil.setupForward("success", mapping, request);
ViewSetupUtil.setupForward() would call findForward("success"), check
if it's an instanceof SetupActionForward, then call the setupView()
method and pass the request. Depending on what the setup entails, a
user may want to break it down into separate statements in the action
so he can check conditions and alternatively return a different
forward altogether.
If you want POJO support, you can do something like:
In this case, SetupActionForward would instantiate the named class and
call the method and pass parameters. Either way, it'd work even
without any changes to Struts core. :)
There are other variations that can be made, of course.
As far as sharing this to other people, I've done something similar
with http://www.rabago.net/struts/redirect/. That one even involved a
custom request processor and the use of a base action. And yes,
people actually use it. :) Of course, sometimes I also just point
them to an attachment I made to Bug 866.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Quoting "Frank W. Zammetti" <[EMAIL PROTECTED]>: > > As much as I hate to say it, sometimes engineers being project managers > is a bad idea. Perhaps open-source community-driven development > projects should come to that conclusion and separate the project > managers from the developers. Just a thought (not even sure *I* would > agree with it yet). Project management in itself isn't a bad thing, but a very good thing. It's when the project managers are perceived to be the bosses of development, instead of its secretaries, that there's a problem. I think there are folks who could contribute alot to open source projects, and benefit the projects greatly, if they were allowed to fill a project manager roll. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
I am not interested in having an upload application accepted by Struts. Why would I be interested in that? The lack of interest is in making Struts accommodate these differences with the way it handles multipart request processing. I changed the application to accommondate that and the entirety of the relevant code is on the wiki in 15 lines. I must have said this a number of times, but somehow that point cannot be heard. Why? I do not mean that I would not donate an application. But, that is a fairly superficial, passing, and uninteresting thing. Having the internals of the framework able to accommodate others as well as myself is not superficial, not passing, and, at least I think, very interesting. No one has responded to that point. That is the point, Ted. Jack On Fri, 11 Mar 2005 16:13:53 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > The underlying problem with the upload proposal on the wiki is > > > "I have a full application, but no sense putting it all here if there is no > > interest." > > The best way to generate interest is to post a working example. If you > want to pique interest, you have to go the whole nine yards. Else, > statements like these become self-fulling prophesies. > > Putting the code up on the wiki is great, but you need to post a > downloadable ZIP someplace with the source code and JARs. (Included a > statement putting it under the Apache License would also be a good > idea.) > > If you don't have Internet space anyplace, send it to me directly, and > I'll park it on Struts SourceForge, or someplace. > > -Ted. > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
[EMAIL PROTECTED] wrote: > Project management in itself isn't a bad thing, but a very good thing. It's when > the project managers are perceived to be the bosses of development, instead of > its secretaries, that there's a problem. I think there are folks who could > contribute alot to open source projects, and benefit the projects greatly, if > they were allowed to fill a project manager roll. I couldn't agree more. As annoying as it is to deal with PMs at work sometimes (and as annoying as I'm sure I am to those under me when I wear the PM hat), it is really a vital role. I absolutely think more rigid PM practices should be brought into the OSS world. It could only make things better. And I absolutely think there should be people with PM skills who *only* do PM chores. Unfortunately, whether anyone cares to admit it or not, egos play a huge role in community-driven development. Egos tend to not going along well with anything "rigid". -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
+42 On Fri, 11 Mar 2005 17:59:46 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Project management in itself isn't a bad thing, but a very good > thing. It's when > > the project managers are perceived to be the bosses of development, > instead of > > its secretaries, that there's a problem. I think there are folks who > could > > contribute alot to open source projects, and benefit the projects > greatly, if > > they were allowed to fill a project manager roll. > > I couldn't agree more. As annoying as it is to deal with PMs at work > sometimes (and as annoying as I'm sure I am to those under me when I > wear the PM hat), it is really a vital role. > > I absolutely think more rigid PM practices should be brought into the > OSS world. It could only make things better. And I absolutely think > there should be people with PM skills who *only* do PM chores. > > Unfortunately, whether anyone cares to admit it or not, egos play a huge > role in community-driven development. Egos tend to not going along well > with anything "rigid". > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Hubert Rabago wrote:
Joe most recently mention this sometime last month:
http://marc.theaimsgroup.com/?l=struts-dev&m=110842402707799&w=2
Yep, I was involved in that thread :) The one thing I will say is that
the whole discussion of "view controllers" and "page prep" is really
different than what I implemented. It is similar without question, but
not the same. In fact, and I say this without ego (which is a rare
thing, I will admit! :) ), I think there is a certain uniqueness to what
I did that is at the very least interesting.
Aside from this, an email I sent to you (well, on the user list, but
on the thread where you mentioned this) also linked to a couple of
threads discussing this feature. That mentioned a few alternatives,
including one from me. I even noted that the message was almost a
year old. :)
http://marc.theaimsgroup.com/?l=struts-user&m=111029587900454&w=2
I didn't read that one until now. Interesting! However, I would make
the same comment... what I did is, while similar, still different.
The difference by the way is the generic nature of my solution... it
doesn't really say much of anything except "for any action mapping
and/or forward, you can execute any number of arbitrary methods of
arbitrary classes". It doesn't push you towards a page-centric
approach, it doesn't force class structures on you, it doesn't tie forms
to forwards or this to that or anything like that. It's very open-ended.
There may be an argument to be made that it's *TOO* generic and open and
therefore open to serious abuse. I could see someone making that argument.
> The 1.3 support includes a change to the config DTD. A 1.2 friendly
change could look something like:
package.SpecificSetupActionForward would either extend a
SetupActionForward, or implement a SetupActionForward. In either
case, a setupView() method would be implemented/overridden.
This is one of the things I was seeking to avoid with my
implementation... I didn't want the classes to be anything other than
POJOs. I didn't want to limit the developer to a single setup method
per class. I also wanted to allow for any number of these calls per
forward. Certainly it can be debated whether that is too much power,
but those were my goals. This suggestion wouldn't accomplish those goals.
The action's return could look like:
return ViewSetupUtil.setupForward("success", mapping, request);
ViewSetupUtil.setupForward() would call findForward("success"), check
if it's an instanceof SetupActionForward, then call the setupView()
method and pass the request. Depending on what the setup entails, a
user may want to break it down into separate statements in the action
so he can check conditions and alternatively return a different
forward altogether.
But this intrinsically ties this to a forward, and it also entails more
code in an Action. I'd prefer a purely declarative answer. I also
think we should be able to do this at the action mapping level as well
as the forward level. Also, would this work for global forwards? My
implementation does.
If you want POJO support, you can do something like:
I personally wouldn't like this as I think set-property is too easy to
abuse (and might be already). For instance, one can do:
FirstName
Frank
LastName
Zammetti
Perfectly valid of course, but not as good, in my mind at least, as:
Frank
Zammetti
Aside from being shorter, which is good for numerous reasons, the second
to me is just a tad clearer in meaning. Not a huge difference I admit,
but a bit. I view set-property like the first example.
In this case, SetupActionForward would instantiate the named class and
call the method and pass parameters. Either way, it'd work even
without any changes to Struts core. :)
Agreed, could work without changes to the core. But I think it makes a
worse compromise: it requires changes on the part of the application
developer. Again, purely declarative was one of my goals.
There are other variations that can be made, of course.
I very much want to discuss them! However, in my mind, any solution
must meet the following criteria:
(1) Must be purely declarative
(2) Must NOT require changes to existing applications
(3) Must work at the action mapping and forward level (both local and
global)
(4) As per everyone else' opinion, must NOT change any Struts classes
(5) As far as I'm concerned, must use POJOs and must allow for an
arbitrary number of method calls in any number of classes per
mapping/forward
My implementation deals with all but #4. Unfortunately, that's the one
point that is killing it being accepted I think :)
As far as sharing this to other people, I've done something similar
with http://www.rabago.net/struts/redirect/. That one even involved a
custom request processor and the use of a base action. And yes,
people actually use it. :) Of course, sometimes I also just point
them to an attachment I made to Bug 866.
That's actually quite co
Re: Storing current ActionContext in ThreadLocal
On Fri, 11 Mar 2005 11:22:54 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 10:08 AM -0600 3/11/05, Hubert Rabago wrote: > >What about using a different class to host the ThreadLocal? > > > It seems arbitrary to me, and more of a burden than simply having a > public static ThreadLocal which most people would ignore -- but if > others prefer this approach, I wouldn't fight it. > I was actually thinking of "Log log = LogFactory.getLog();", although I admit there tons more differences than similarities. Just to be clear, I'm not pushing this approach, just discussing it. On the initial idea, where you'd declare the ThreadLocal on the interface - did you mean the accessors would be on the ActionContext interface as well? If so, an implementation may choose a different way to provide a result, ignoring the ThreadLocal declared on the interface, right? I haven't caught up yet on the chain implementation. We have ActionContext as an interface. Is there going to be a way to let the user provide a different instance, or is extending ComposableRequestProcessor the recommended approach? If a factory is created to produce ActionContext instances, the getCurrentContext() method can be placed there, reducing the "arbitrary" vibe. > >The instance would be set by the RequestProcessor at the start of the > >chain after the context is created. > > Yes, no matter where we store the ActionContext, my intent would be > to set this in process() right after contextInstance(...). > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Storing current ActionContext in ThreadLocal
Joe Germuska wrote: So, I was just about to add support for static access to the "current" ActionContext using ThreadLocal, and then I realized that this approach is more commonly used with classes than with interfaces. Since ActionContext is an interface, we'd have to do something like this: public static final ThreadLocal currentInstance = new ThreadLocal(); Is it too weird to have this as a public member? Is there some artful way to hide it more? Of course, we'd have public static void setCurrentInstance(ActionContext ctx) Why not just put the ThreadLocal the same place you put these methods wrapping it? Interfaces can't have static methods so you'll have to have it on some concrete class somewhere, yes? -Paul and public ActionContext getCurrentInstance() but I'm sketched out at having to leave the member itself public. That said, I'm still happier with ActionContext as an interface than an abstract class. Any words of wisdome, or should I just go ahead and do this? Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
