[Apache Struts Wiki] New: ModuleConfigImpl
Date: 2004-07-07T23:03:48 Editor: 202.70.161.194 Wiki: Apache Struts Wiki Page: ModuleConfigImpl URL: http://wiki.apache.org/struts/ModuleConfigImpl no comment New Page: Describe ModuleConfigImpl here. this caused problem when re-deploying struts program. public void org.apache.struts.config.impl.ModuleConfigImpl.addFormBeanConfig(org.apache.struts.config.FormBeanConfig) doesn't match with the one from Digester, it refers to old-instance. louis.wang 08/jul/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
discussing RequestWrapperI (was FW: [Myfaces-develop] Fwd: MyFaces - Struts
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matthias Wessendorf
Sent: Wednesday, June 23, 2004 9:59 AM
To: [EMAIL PROTECTED]
Subject: RE: [Myfaces-develop] Fwd: MyFaces - Struts
Oliver
i used the examples, that were shipped via struts-faces.
there is a *link* to URL
http://localhost:8080/struts-faces/editRegistration.do?action=Create
okay, struts does it's way (the FacesRequestProcessor of
integration-lib)
Action.clazz gets processed. it returns an ActionForward-Objekt. (called
success), but in struts-config the Actionforward points to a path
/registration.faces. ok fine.
in FacesRequestProcessor, that is used instead of *default*
RequestProcessor, the method doForward() checks, if URI
(/registration.faces) is an Struts-Request. it is not that case.
so it creates a FacesContext
code
// Create a FacesContext for this request if necessary
LifecycleFactory lf = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = // FIXME - alternative lifecycle ids
lf.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
FacesContext context = FacesContext.getCurrentInstance();
if (context == null) {
if (log.isTraceEnabled()) {
log.trace( Creating new FacesContext for ' + uri +
');
}
FacesContextFactory fcf = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
context = fcf.getFacesContext(servlet.getServletContext(),
request,
response, lifecycle);
}
/code
after that it creates a new ViewRoot, delegates the context to our
JSPViewHandler, finally it calls responseComplete() code
// Create a new view root
ViewHandler vh = context.getApplication().getViewHandler();
if (log.isTraceEnabled()) {
log.trace( Creating new view for ' + uri + ');
}
context.setViewRoot(vh.createView(context, uri));
// Cause the view to be rendered
if (log.isTraceEnabled()) {
log.trace( Rendering view for ' + uri + ');
}
lifecycle.render(context);
context.responseComplete();
/code
so the Servlet-Path is still the *.do - thing,
that code works *directly* with RI,
This will be the correct one in
your case
but might be wrong in some other case.
jupp :-) that was the reason of my question.
do you need any more information on that?
Cheers,
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Myfaces-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/myfaces-develop
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Struts-Faces] wrapping a HttpServletRequest
Craig, i tried the struts-faces-example with myfaces and RI (worked out of the box) this happens with myfaces: i clicked LINK editRegistration.do?action=Create and become IllegalArgumentException: could not find pathMapping for servletPath = /editRegistration.do requestPathInfo = null net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.getServletMap ping(JspViewHandlerImpl.java:407) net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.renderView(Js pViewHandlerImpl.java:185) org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandl erImpl.java:134) net.sourceforge.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.jav a:282) org.apache.struts.faces.application.FacesRequestProcessor.doForward(Face sRequestProcessor.java:148) okay, after that i looked in myfaces JspViewHandlerImpl.java and noticed we only react on FacesServlet-Mappings (eg *.faces, /faces/*,...) i changed it, now it works but as a result of following discussion on myfaces-mailinglist (see the three forwards) i decided to create that wrapper, that sets requestPath from struts (*do) to faces (*.faces) now it works again with myfaces and of course RI so perhaps you have other hints on that? Matthias -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 3:27 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: Re: [Struts-Faces] wrapping a HttpServletRequest Matthias Wessendorf wrote: Hi, i tried the faces-struts-lib with RI. It works. Matthias, Could you please explain in more detail exactly what appears to you to be a bug in the struts-faces library that requires this wrapper, and also what unspecified behavior in the RI is being relied on? This is not at all obvious to me -- and I intend to pull the wrapper back out unless you can show me why it's needed. The explanation below, and all the mail threads and messages on bug 29809, still haven't made it clear to me what the problems you are trying to solve really are. Craig But not with Open-Source-Implementation *MyFaces*. i notices, that in struts-faces the servletPath is a *.do (or that for struts). But it must be an faces-mapping for servlet-Path (*.faces e.g.) the FacesRequestProcessor know if request is for ActionSerclet or not. If not, it delegates it to JSF-Impl. Base of checking is a URI, that is configed in forward name=success path=/test.faces/ (e.g.) so i wrote a simple HttpServletRequestWrapper which wrappes the uri as new ServletPath. now everything is fine. like this (in FacesRequesProcessor) code FacesContextFactory fcf = (FacesContextFactory) FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY); HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper(request,uri); context = fcf.getFacesContext(servlet.getServletContext(), wrapper, response, lifecycle); /code it is not an error in myfaces-impl. it is an bug in the RI. please see the email of Ted Husted (on myfaces-list) ted On Wed, 23 Jun 2004 20:21:49 -0700, [EMAIL PROTECTED] wrote: the MyFaces implementation is correct in this aspect and I don't think we should clone the bugs of the RI just because struts relies on them. I hope spec-compliant does not mean we have to have the same bugs the RI has ;-)? By the way, if the RI is fixed, struts will not work there any longer, too. The RI and Struts-Faces were created in tandem, so it's not surprising the same assumptions crop up in each. But, no, specification-compliant does not mean that we should rely on bugs in any implementation, including the RI. In fact, the Struts tradition has been to expose bugs in implementations so that vendors are compelled to fix them. If you develop any patches you would like applied, please bring them to my attention. Once we can get 1.2.1 out-the-door (could be this week), we will be setting up several subprojects, including Struts-Faces, that can be released separately. So the clean solution from my point of view is to fix the issue in struts. For example it would be possible to wrap the servlet request before the FacesContext is created. The wrapper takes the uri of the view to be displayed to simulate a valid jsf servlet path for the view manager. What do you think? Oliver /ted and here is the simple wrapper-class: i can apply a patch, but on that i will do a bit better documentation of that wrapper-class Cheers, Matthias /* * Copyright 2002,2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You
discussing RequestWrapperII (was FW: [Myfaces-develop] Fwd: MyFaces - Struts)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oliver
Rossmueller
Sent: Thursday, June 24, 2004 1:53 AM
To: [EMAIL PROTECTED]
Subject: Re: [Myfaces-develop] Fwd: MyFaces - Struts
Manfred Geiler wrote:
Matthias, Oliver,
After some investigation I found out the following:
The RI works, because they always default to extension mapping. So,
like MyFaces they won't find the right mapping in the web.xml, but
since they do not handle this as an error condition, it works.
Matthias,
Your patch might work in many cases but there are scenarios where it
is subject to fail. The addressed loop's purpose is to find the actual
servlet mapping that led to the faces request. Your patch would cut
off the comparison of the actual extension and the mapping extension.
So the loop would always exit on the very first extension mapping.
This will miss the goal. Imagine two mappings in web.xml: one
extension mapping for struts *.do, one mapping for direct calls to
faces *.jsf.
If there is a *.jsf call, the loop will find the first *.do
mapping and assume, that this is the seeked mapping. On a navigation
the destination viewId will get the wrong extension .do instead of
.jsf and the following request will wrongly go to struts.
There are two possible solutions I think:
1. Write a StrutsJspViewHandlerImpl as Oliver suggested
-1 from me, because different configuration needed for struts
2. After the loop finishes without a match: instead of throwing an
exception, log a warning only (struts folk can set the log severity
for JspViewHandlerImpl to error if they feel bothered) and return
null. Of course, depending methods must handle this default case.
+1 from me, because the mapping is not that critical (it works or it
works not, it won't change daily for an application), we get a
warning, which is enough hint if there are problems and we are more RI
compatible
Manfred,
the MyFaces implementation is correct in this aspect and I don't think
we should clone the bugs of the RI just because struts relies on them. I
hope spec-compliant does not mean we have to have the same bugs the RI
has ;-)? By the way, if the RI is fixed, struts will not work there any
longer, too.
So the clean solution from my point of view is to fix the issue in
struts. For example it would be possible to wrap the servlet request
before the FacesContext is created. The wrapper takes the uri of the
view to be displayed to simulate a valid jsf servlet path for the view
manager. What do you think?
Oliver
Thanks,
Manfred
Oliver
i used the examples, that were shipped via struts-faces.
there is a *link* to URL
http://localhost:8080/struts-faces/editRegistration.do?action=Create
okay, struts does it's way (the FacesRequestProcessor of
integration-lib)
Action.clazz gets processed. it returns an ActionForward-Objekt.
(called success), but in struts-config the Actionforward points to
a path /registration.faces. ok fine.
in FacesRequestProcessor, that is used instead of *default*
RequestProcessor, the method doForward() checks, if URI
(/registration.faces) is an Struts-Request.
it is not that case.
so it creates a FacesContext code
// Create a FacesContext for this request if necessary
LifecycleFactory lf = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = // FIXME - alternative lifecycle ids
lf.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
FacesContext context = FacesContext.getCurrentInstance();
if (context == null) {
if (log.isTraceEnabled()) {
log.trace( Creating new FacesContext for ' + uri +
');
}
FacesContextFactory fcf = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
context =
fcf.getFacesContext(servlet.getServletContext(),
request,
response, lifecycle);
}
/code
after that it creates a new ViewRoot, delegates the context to our
JSPViewHandler, finally it calls responseComplete() code
// Create a new view root
ViewHandler vh = context.getApplication().getViewHandler();
if (log.isTraceEnabled()) {
log.trace( Creating new view for ' + uri + ');
}
context.setViewRoot(vh.createView(context, uri));
// Cause the view to be rendered
if (log.isTraceEnabled()) {
log.trace( Rendering view for ' + uri + ');
}
lifecycle.render(context);
context.responseComplete();
/code
so the Servlet-Path is still the *.do - thing,
that code works *directly* with RI,
This will be the correct one in your case but might be wrong in some
other case.
jupp :-) that was the reason of my question.
do you need any more information on that?
Cheers,
RE: Struts 1.2.1 release?
I'm now testing, tagging, and rolling Struts 1.2.1. Please stand by :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts build.properties.sample.lib
husted 2004/07/08 06:19:57
Added: .build.properties.sample.lib
Log:
Add a simplified build.properties file for use by developers who are not actively
involved in Jakata Commons development. This template assumes the developer is using
the JARs from our lib distribution.
Revision ChangesPath
1.1 jakarta-struts/build.properties.sample.lib
Index: build.properties.sample.lib
===
# -
# build.properties.sample.lib
#
# This is a simplified build.properties file that assumes you are using the
# lib directory distributed with Struts, rather than building against
# the development versions of each of the Jakarta Commons projects.
#
# If you are not active in Jakarta Commons development, this is the
# preferred template for your build.properties file.
#
# First, you will need to install Ant 1.5.4 per the instructions on the
# Ant website ant.apache.org.
#
# Then, to build Struts using this file,
# * copy it as build.properties, and
# * extract the Stuts Library distribution to a folder named lib under
# your Struts distribution
# * place a copy of the servlet.jar for your container in the same folder.
#
# If you prefer to keep the JARs at another location, the properties
# at the very top of the file may changed. If you require more versatility
# in specifiying JAR locations, see the original build.properties.sample file.
#
# Only the shared properties are required for a typical build.
#
# Running the Catcus unit tests is tricky. See the DEV list if you need help
# with those.
#
# Although experimental, new developers may want to try the Maven build.
# After installing Maven (maven.apache.org), you can change to your
# jakarta-struts directory and execute:
#
# maven
#
# All the dependencies will be automatically downloaded and installed for
# you.
#
# $Id: build.properties.sample.lib,v 1.1 2004/07/08 13:19:57 husted Exp $
# -
compile.deprecation=true
# Properties related to local files
# -
# TODO: List of packages needed to be installed to run all these tasks
# -- required for shared --
# struts-lib.home - Where the Struts library is kept
struts-lib.home=./lib
# servlet.home - Where JAR file containing the Servlet API classes is kept
servlet.home=/opt/JavaSoft/lib
# Compile against either version 2.2 or 2.3
servlet.jar=${servlet.home}/servletapi.jar
# -- required for contrib -
# jstl.home - Where the JSTL distribution is kept
jstl.home = /opt/Taglibs/jakarta-taglibs-standard-1.0.5
# struts.home
struts.home = ../../
# -- required for testing -
junit.home = /opt/JUnit
# JUnit jar file, version 3.81 required
junit.jar = ${junit.home}/junit3.8.1/junit.jar
# apache.home - Where other precompiled jar files from Apache are kept
# This may (optionally) include Ant, Cactus,Tomcat, and Xerces
apache.home=/opt/Apache
# -- used by other optional tasks---
# The JAR file containing the Checkstyle package version 2.4, if available. If
# you do not have Checkstyle installed, do not set this property.
# checkstyle.jar = /opt/CheckStyle/checkstyle-2.4/checkstyle-all-2.4.jar
# The Directory containing the PMD package distribution, 1.2.1, if available. If
# you do not have PMD installed, do not set this property.
# pmd.home = /opt/pmd/pmd-1.2.1
# Properties related to Struts shared
# -
# For more about these dependencies, see the installation page in the UserGuide
antlr.jar=${struts-lib.home}/antlr.jar
commons-beanutils.jar=${struts-lib.home}/commons-beanutils.jar
commons-collections.jar=${struts-lib.home}/commons-collections.jar
commons-digester.jar=${struts-lib.home}/commons-digester.jar
commons-fileupload.jar=${struts-lib.home}/commons-fileupload.jar
commons-lang.jar=${struts-lib.home}/commons-lang.jar
commons-logging.jar=${struts-lib.home}/commons-logging.jar
commons-validator.jar=${struts-lib.home}/commons-validator.jar
jakarta-oro.jar=${struts-lib.home}/jakarta-oro.jar
# Properties related to Struts contrib
# -
# These links to the JSTL jar files are only required for building the
# Struts-EL contrib library. If they are not present, it will not build that
# contrib library (although it doesn't prevent you from building it directly in
# contrib/struts-el.
jstl.jar =${jstl.home}/lib/jstl.jar
jstl-standard.jar=${jstl.home}/lib/standard.jar
jstl.tld.dir =${jstl.home}/tld
# Properties related to
cvs commit: jakarta-struts/doc/userGuide installation.xml
husted 2004/07/08 06:22:24
Modified:.build-webapp.xml build.properties.sample build.xml
project.xml
doc/userGuide installation.xml
Log:
(Hopefully) final round of changes before tagging 1.2.1.
Revision ChangesPath
1.17 +0 -1 jakarta-struts/build-webapp.xml
Index: build-webapp.xml
===
RCS file: /home/cvs/jakarta-struts/build-webapp.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- build-webapp.xml 7 Jul 2004 11:12:02 - 1.16
+++ build-webapp.xml 8 Jul 2004 13:22:23 - 1.17
@@ -173,7 +173,6 @@
pathelement location=${commons-fileupload.jar}/
pathelement location=${commons-logging.jar}/
pathelement location=${commons-validator.jar}/
- pathelement location=${jdbc20ext.jar}/
pathelement location=${servlet.jar}/
pathelement location=${struts.libs}/struts.jar/
pathelement location=${webapp.libs}/
1.53 +8 -18 jakarta-struts/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-struts/build.properties.sample,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- build.properties.sample 8 Mar 2004 23:27:34 - 1.52
+++ build.properties.sample 8 Jul 2004 13:22:23 - 1.53
@@ -32,31 +32,31 @@
# if you are going to execute the deploy.catalina target.
catalina.home=${apache.home}/jakarta-tomcat-4.0.6
-# The JAR file containing the Beanutils package (Version 1.6.1 or later)
+# The JAR file containing the Beanutils package (see Installation page)
# from the Jakarta Commons project.
commons-beanutils.jar=${commons-lib.home}/beanutils/dist/commons-beanutils.jar
-# The JAR file containing the Collections package (Version 2.1 or later)
+# The JAR file containing the Collections package (see Installation page)
# from the Jakarta Commons project.
commons-collections.jar=${commons-lib.home}/collections/dist/commons-collections.jar
-# The JAR file containing the Digester package (Version 1.5 or later)
+# The JAR file containing the Digester package (see Installation page)
# from the Jakarta Commons project.
commons-digester.jar=${commons-lib.home}/digester/dist/commons-digester.jar
-# The JAR file containing the FileUpload package (Version 1.0 or later)
+# The JAR file containing the FileUpload package (see Installation page)
# from the Jakarta Commons project.
commons-fileupload.jar=${commons-lib.home}/fileupload/dist/commons-fileupload-1.0.jar
-# The JAR file containing the Lang package (Version 1.0.1 or later)
+# The JAR file containing the Lang package (see Installation page)
# from the Jakarta Commons project.
commons-lang.jar=${commons-lib.home}/lang/dist/commons-lang-2.0.jar
-# The JAR file containing the Logging package (Version 1.0.3 or later)
+# The JAR file containing the Logging package (see Installation page)
# from the Jakarta Commons project.
commons-logging.jar=${commons-lib.home}/logging/dist/commons-logging.jar
-# The JAR file containing the Validator package (Version 1.1.2 or later)
+# The JAR file containing the Validator package (see Installation page)
# from the Jakarta Commons project.
commons-validator.jar=${commons-lib.home}/validator/dist/commons-validator.jar
@@ -106,16 +106,6 @@
# you do not have PMD installed, do not set this property.
pmd.home = /Java/Programs/SourceForge/pmd-1.2.1
-#Maven Variables ###
-# CVS Start Change Log date
-cvs.start=17 April 2003
-
-
-# If you are using ssh tunneling have a .cvspass file setup
-cvs.developer.host=localhost
-cvs.developer.id=rleland
-
-#End of Maven Variables
###
# Properties related to Struts Contrib
# -
1.133 +1 -1 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -r1.132 -r1.133
--- build.xml 7 Jul 2004 17:00:25 - 1.132
+++ build.xml 8 Jul 2004 13:22:23 - 1.133
@@ -148,7 +148,7 @@
property name=project.name value=jakarta-struts/
!-- Version of the project --
-property name=project.version value=1.2.1-dev/
+property name=project.version value=1.2.1/
!-- == Derived Properties --
1.30 +21 -10jakarta-struts/project.xml
Index: project.xml
[VOTE] Struts 1.2.1 Alpha, Beta, or GA? (was Re: Struts 1.2.1 release)
The repository is tagged for STRUTS_1_2_1, and the release is available for review at * http://www.apache.org/~husted/struts/v1.2.1 Once you have had a chance to review the release, please respond as to whether we should [ ] Keep this release at Alpha. Followup reports filed to Bugzilla. [ ] Promote this release to Beta and announce on Struts User for further testing [ ] Promote this release to General Availability now (*) (*) A vote to promote Struts 1.2.1 to GA must follow a corresponding vote to promote Commons Validator 1.1.3 to GA. Releases are subject to majority approval of the PMC, and the status may be changed at any time. Votes and feedback from *all* Struts developers is very welcome. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.2.1 release?
Ted, I'm now testing, tagging, and rolling Struts 1.2.1. Please stand by :) As far as I can tell by monitoring this list, 1.2.1 seems to fix only face related few bugs. It didn't pick most patches available in bugzilla. Could you tell comitters pick patches for the next release? Only by a chance? I'm not complaining. I just want to know what else I can do to make sure my patch will be picked next time. Regards, -- KUROSAKA (Kuro) Teruhiko, San Francisco, California, USA Internationalization Consultant --- now available for new contracts! http://www.bhlab.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] wrapping a HttpServletRequest
Matthias Wessendorf wrote: Craig, i tried the struts-faces-example with myfaces and RI (worked out of the box) this happens with myfaces: i clicked LINK editRegistration.do?action=Create and become IllegalArgumentException: could not find pathMapping for servletPath = /editRegistration.do requestPathInfo = null net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.getServletMap ping(JspViewHandlerImpl.java:407) net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.renderView(Js pViewHandlerImpl.java:185) org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandl erImpl.java:134) net.sourceforge.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.jav a:282) org.apache.struts.faces.application.FacesRequestProcessor.doForward(Face sRequestProcessor.java:148) okay, after that i looked in myfaces JspViewHandlerImpl.java and noticed we only react on FacesServlet-Mappings (eg *.faces, /faces/*,...) i changed it, now it works but as a result of following discussion on myfaces-mailinglist (see the three forwards) i decided to create that wrapper, that sets requestPath from struts (*do) to faces (*.faces) now it works again with myfaces and of course RI so perhaps you have other hints on that? Matthias Matthias, Thanks for the forwards ... I'm going to get out my trusty debugger and walk through this in detail. At first glance, it appears more likely that the problem is in Struts, calculating the view id in the created component tree (the processing should convert /registration.faces to /registration.jsp in the particular example webapp, before calling ViewHandler.renderView()). If that were to be done, a ViewHandler implementation that relied solely on the view id *should* work, with no wrapper -- we'll see if that prediction comes true or not. This chunk of code is bringing back bad memories :-) of the work it took to get this to run at all. I see that it needs some more work :-) :-). The change in servletPath is part of what a RequestDispatcher.forward() call normally does (that's what happens on a normal Struts request). I ran into quite a few difficulties making an RD.forward() to the Faces servlet do the right thing here -- but if using a wrapper ends up being the right solution, there's some other things we'll need to change as well so that it works with a prefix mapped FacesServlet (/faces/*) too. More news as I debug this further. Craig PS: There was an implication in the mail and bug report comments that the RI is violating the spec in its view handler implementation. If it is, I'd like to fix that, and my commit privileges there still work :-). Can you point to any specific place where that might be true? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 1.2.1 release? - patches take-up
Given that the committers are busy people, I'd guess one way to get a patch considered is to actively seek out struts developers who are experiencing the problem that your patch fixes, and get them to test it for you - you're doing them a favour, and if several of them add a 'works for me' to the ticket, there's a better chance it'll get noticed by the commiters. Would I be right in assuming your patch is the one on bug 29824 - that handles parameters that are not encoded in ISO-8859-1? That actually sounds like it /might/ solve a problem I recently had with struts - a form was turning the acute 'e' in 'café' into garbage, hmm! I'd been thinking I needed to change character encoding in tomcat or something, but I'll try applying your patch and see what happens. Myself, I've got a teenie-tiny patch to add message parameter XML-escaping to html:messages (bug 26112) that isn't going anywhere - it hasn't received any feedback. Still, running a patch version of Struts does make one feel 'special' :-) Roberto -Original Message- From: KUROSAKA Teruhiko [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 15:58 To: Struts Developers List Subject: Re: Struts 1.2.1 release? As far as I can tell by monitoring this list, 1.2.1 seems to fix only face related few bugs. It didn't pick most patches available in bugzilla. Could you tell comitters pick patches for the next release? Only by a chance? I'm not complaining. I just want to know what else I can do to make sure my patch will be picked next time. Regards, -- KUROSAKA (Kuro) Teruhiko, San Francisco, California, USA Internationalization Consultant --- now available for new contracts! http://www.bhlab.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java
James Holmes wrote: The problem is/was that the s:base tag was rendering invalid base element: The JSPs in the struts-faces war (i.e. logon.jsp) have an s:base id=base/ that generates the following: base href=/struts-faces/logon.faces / The href should have a fully qualified url (i.e. http://...) right? This causes the browser to not be able to find the stylesheet for the page. Not only should it be absolute (although the browser I tried it with actually still worked right with a server relative path), it needs to be the path of the JSP page itself. That isn't critical if you use extension mapping for FacesServlet, but it really matters if you use prefix mapping, where the generated HREF would have been /struts-faces/faces/logon.jsp and therefore added a directory level. I presume you have fixed after seeing your last commit? Yep, it should be fixed now ... can you give it a try? -James Craig -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 8:33 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java James Holmes wrote: Just curious if these changes fix the problem with the broken s:base tag? Basically the tag was outputting and invalid href attribute on the generated base tag. This is a problem almost everyone was experiencing. Myself included. Sorry to be dense, but *what* broken output? What's wrong with it? Is there a bugzilla report on this? Both example apps work for me on Tomcat 4.1.29 and 5.0.25. But that was true before today's changes too; and I didn't change anything that should affect the URL being created. -James Craig - 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]
Re: Struts 1.2.1 release?
At 7:58 AM -0700 7/8/04, KUROSAKA Teruhiko wrote: Ted, I'm now testing, tagging, and rolling Struts 1.2.1. Please stand by :) As far as I can tell by monitoring this list, 1.2.1 seems to fix only face related few bugs. It didn't pick most patches available in bugzilla. Could you tell comitters pick patches for the next release? Only by a chance? I'm not complaining. I just want to know what else I can do to make sure my patch will be picked next time. As far as I know, there's no formal way in which patches are applied. Obviously, non-enhancements are applied sooner, especially if there is a test case available to help guarantee that the patch fixes the problem and doesn't cause others. As for enhancement requests, Ted has indicated that he is most interested in applying patches that have a healthy discussion in Bugzilla, because it indicates to him that there are interested parties. Bugzilla also supports votes for patches, and I think that it makes sense for people to vote for enhancements which they think would be particularly good additions to Struts. Finally, users who are really interested in helping out can apply patches themselves to their own CVS repository and provide feedback about whether they work as advertised and don't break anything. You can understand that committers are hesitant to apply every enhancement simply because it has been requested. I'd be reluctant to commit a patch if I didn't feel that I could test it adequately. Hence, it is helpful if in addition to submitting enhancements other users of Struts can also test enhancements that they think would be good to add. Just my opinion (plus one paraphrase of Ted :^) Joe PS While I was composing this, Roberto wrote: Given that the committers are busy people, I'd guess one way to get a patch considered is to actively seek out struts developers who are experiencing the problem that your patch fixes, and get them to test it for you - you're doing them a favour, and if several of them add a 'works for me' to the ticket, there's a better chance it'll get noticed by the commiters. As long as developers is understood as any user who is willing to treat the source code as his own, I agree completely -- just don't think that developers == committers. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)
On Thu, 8 Jul 2004, Joe Germuska wrote: At 12:41 AM -0700 7/6/04, Craig McClanahan wrote: I've updated my nightly build script (effective with the 20040706 build) to use the following dependnet libraries, which I'm assuming corresponds to what we'll actually use in a Struts 1.2.1 release. Can whoever is going to be release manager for this confirm the version numbers? jakarta-oro 2.0.7 I just happened to be looking this over to check the versions in the Struts 1.2.1 distribution and I noticed that we're using Oro 2.0.7 but the current release is 2.0.8. Is our general plan always to use the newest release of all libraries? If so, we should update the Oro dependency. Small, I'm sure, but still... I think it would be good to update to ORO 2.0.8, since there are a couple of fixes to regexp matching in there. See: http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-type=text/plain Of course, it's also easy for people to upgrade it themselves if they encounter the problems, so it's not that big of a deal. -- Martin Cooper Joe -- Joe Germuska[EMAIL PROTECTED] http://blog.germuska.comIn fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - 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]
FW: [Myfaces-develop] Fwd: MyFaces - Struts
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 6:22 PM
To: '[EMAIL PROTECTED]'
Subject: FW: [Myfaces-develop] Fwd: MyFaces - Struts
Hey Craig,
this email (from manfred geiler) i missed
after that oliver pointed out, that RI has a bug.
do you need more?
Matthias
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Manfred Geiler
Sent: Wednesday, June 23, 2004 1:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [Myfaces-develop] Fwd: MyFaces - Struts
Matthias, Oliver,
After some investigation I found out the following:
The RI works, because they always default to extension mapping. So, like
MyFaces they won't find the right mapping in the web.xml, but since they
do not handle this as an error condition, it works.
Matthias,
Your patch might work in many cases but there are scenarios where it is
subject to fail. The addressed loop's purpose is to find the actual
servlet mapping that led to the faces request. Your patch would cut off
the comparison of the actual extension and the mapping extension. So the
loop would always exit on the very first extension mapping. This will
miss the goal. Imagine two mappings in web.xml: one extension mapping
for struts *.do, one mapping for direct calls to faces *.jsf. If
there is a *.jsf call, the loop will find the first *.do mapping
and assume, that this is the seeked mapping. On a navigation the
destination viewId will get the wrong extension .do instead of .jsf and
the following request will wrongly go to struts.
There are two possible solutions I think:
1. Write a StrutsJspViewHandlerImpl as Oliver suggested
-1 from me, because different configuration needed for struts
2. After the loop finishes without a match: instead of throwing an
exception, log a warning only (struts folk can set the log severity for
JspViewHandlerImpl to error if they feel bothered) and return null. Of
course, depending methods must handle this default case.
+1 from me, because the mapping is not that critical (it works or it
works not, it won't change daily for an application), we get a warning,
which is enough hint if there are problems and we are more RI compatible
Thanks,
Manfred
Oliver
i used the examples, that were shipped via struts-faces.
there is a *link* to URL
http://localhost:8080/struts-faces/editRegistration.do?action=Create
okay, struts does it's way (the FacesRequestProcessor of
integration-lib)
Action.clazz gets processed. it returns an ActionForward-Objekt.
(called success), but in struts-config the Actionforward points to a
path /registration.faces. ok fine.
in FacesRequestProcessor, that is used instead of *default*
RequestProcessor, the method doForward() checks, if URI
(/registration.faces) is an Struts-Request.
it is not that case.
so it creates a FacesContext
code
// Create a FacesContext for this request if necessary
LifecycleFactory lf = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle = // FIXME - alternative lifecycle ids
lf.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
FacesContext context = FacesContext.getCurrentInstance();
if (context == null) {
if (log.isTraceEnabled()) {
log.trace( Creating new FacesContext for ' + uri +
');
}
FacesContextFactory fcf = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
context = fcf.getFacesContext(servlet.getServletContext(),
request,
response, lifecycle);
}
/code
after that it creates a new ViewRoot, delegates the context to our
JSPViewHandler, finally it calls responseComplete() code
// Create a new view root
ViewHandler vh = context.getApplication().getViewHandler();
if (log.isTraceEnabled()) {
log.trace( Creating new view for ' + uri + ');
}
context.setViewRoot(vh.createView(context, uri));
// Cause the view to be rendered
if (log.isTraceEnabled()) {
log.trace( Rendering view for ' + uri + ');
}
lifecycle.render(context);
context.responseComplete();
/code
so the Servlet-Path is still the *.do - thing,
that code works *directly* with RI,
This will be the correct one in
your case
but might be wrong in some other case.
jupp :-) that was the reason of my question.
do you need any more information on that?
Cheers,
---
This SF.Net email sponsored by Black Hat Briefings Training. Attend
Black Hat Briefings Training, Las Vegas July 24-29 - digital self
defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)
Joe Germuska wrote: At 12:41 AM -0700 7/6/04, Craig McClanahan wrote: I've updated my nightly build script (effective with the 20040706 build) to use the following dependnet libraries, which I'm assuming corresponds to what we'll actually use in a Struts 1.2.1 release. Can whoever is going to be release manager for this confirm the version numbers? jakarta-oro 2.0.7 I just happened to be looking this over to check the versions in the Struts 1.2.1 distribution and I noticed that we're using Oro 2.0.7 but the current release is 2.0.8. Is our general plan always to use the newest release of all libraries? If so, we should update the Oro dependency. Small, I'm sure, but still... Joe Has anyone tested with 2.0.8? If so, I don't have any problem with picking this up in a subsequent 1.2.x release. I'll update the nightly build dependencies for tonight's run. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.2.1 release? - patches take-up
Roberto and all, Given that the committers are busy people, I'd guess one way to get a patch considered is to actively seek out struts developers who are experiencing the problem that your patch fixes, and get them to test it for you - you're doing them a favour, and if several of them add a 'works for me' to the ticket, there's a better chance it'll get noticed by the commiters. Here's a problem I see in this process My patch (for 29824, you guesset it right) is to make it easy for casual struts developers to use Struts. The target audience is not serious developers. They are not interested in (or even capable of) building Struts libraries. They would rather apply a workaround than building Struts by themselves. Is it OK that I create a personal version of Struts that has my patch applied and publish the binary from my private site? Would I be right in assuming your patch is the one on bug 29824 - that handles parameters that are not encoded in ISO-8859-1? That actually sounds like it /might/ solve a problem I recently had with struts - a form was turning the acute 'e' in 'café' into garbage, hmm! Your problem is probably due to something else. The offending character in your problem is part of ISO-8859-1 which is a default charset; my patch would not fix your problem. If you tell me your problem (in individual email), I can take a look. Regards, -- KUROSAKA (Kuro) Teruhiko, San Francisco, California, USA Internationalization Consultant --- now available for new contracts! http://www.bhlab.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)
On Thu, 08 Jul 2004 09:36:42 -0700, Craig McClanahan wrote: Has anyone tested with 2.0.8? If so, I don't have any problem with picking this up in a subsequent 1.2.x release. I'll update the nightly build dependencies for tonight's run. I did consider changing the dependency, but decided against an 11th hour change. If people think it's a worthwhile change, we can roll Struts 1.2.2 after we see if there is feedback on other issues. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying Struts
Another approach to simplifying Struts would be to add more flexibility to the
struts-config. One patch I'd love to apply would provide the extends capability
found in Tiles to all the Struts elements. This would suck a lot of the redundant,
bug-generating redundancy [:)] out of larger modules.
Another patch I'd like to see is support for including a properties file, a la Ant and
iBATIS. People could then use ${properties} in the Struts config -- another redundancy
killer [:)]
A very cool usage would be to import that same properties file into the Struts config
and your source code, which might yield a way to share tokens like success and
failure -- jumping the XML gap.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)
Has anyone tested with 2.0.8? If so, I don't have any problem with picking this up in a subsequent 1.2.x release. I'll update the nightly build dependencies for tonight's run. I've been running a Struts 1.2.x app against ORO 2.0.8 for several months using at least email validation and having no problems. Martin is right that it's trivial for users to upgrade. I think we should update nightlies and not worry about it for Struts 1.2.1 and not bother with a Struts 1.2.2 if it's just to roll that in. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
s:base tag fixed!
I re-ran the struts-faces example app this morning and it is working properly, generating the proper fully-qualified href for the base tag. It looks like your fixes are working. -James -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 10:49 AM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java James Holmes wrote: The problem is/was that the s:base tag was rendering invalid base element: The JSPs in the struts-faces war (i.e. logon.jsp) have an s:base id=base/ that generates the following: base href=/struts-faces/logon.faces / The href should have a fully qualified url (i.e. http://...) right? This causes the browser to not be able to find the stylesheet for the page. Not only should it be absolute (although the browser I tried it with actually still worked right with a server relative path), it needs to be the path of the JSP page itself. That isn't critical if you use extension mapping for FacesServlet, but it really matters if you use prefix mapping, where the generated HREF would have been /struts-faces/faces/logon.jsp and therefore added a directory level. I presume you have fixed after seeing your last commit? Yep, it should be fixed now ... can you give it a try? -James Craig -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 8:33 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java James Holmes wrote: Just curious if these changes fix the problem with the broken s:base tag? Basically the tag was outputting and invalid href attribute on the generated base tag. This is a problem almost everyone was experiencing. Myself included. Sorry to be dense, but *what* broken output? What's wrong with it? Is there a bugzilla report on this? Both example apps work for me on Tomcat 4.1.29 and 5.0.25. But that was true before today's changes too; and I didn't change anything that should affect the URL being created. -James Craig - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
