Re: [OT] IP Clearance for Tiles-Kaolin: seeking a volunteer
Antonio, in case you don't find sb. w/ in the next week. I'll volunteer to help (I did it some weeks ago already for my employer) -M On Thu, Apr 10, 2008 at 5:42 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: Dear friends, First of all, sorry for the cross posting. I am Antonio Petrelli, PMC Member of Apache Tiles. We would like to integrate Dimensions with the new name of Kaolin inside the Tiles codebase: http://mutidimensions.sourceforge.net/ The only developers of this projects are Aaron Roller and me. Aaron is willing to give his software grant to donate it to ASF. Currently I am in search of a volunteer for the IP clerance processing. I already asked Tiles' PMC Chair (Greg Reddin) but he is too busy to help. I already asked the Incubator mailing list, with no answer. If anybody can help me, I will appreciate it much :-) Thanks in advance Antonio -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] commandLink obsolete ?
wow, it is still there :) On 10/27/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: commandLink was create in 2004, b/c of a RI bug. I guess (or assume) that it has been fixed there. works fine w/ MyFaces. however inside trinidad/adf the commandLink will not work ... -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] commandLink obsolete ?
the bug, so can sb apply the patch ? On 10/28/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: wow, it is still there :) On 10/27/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: commandLink was create in 2004, b/c of a RI bug. I guess (or assume) that it has been fixed there. works fine w/ MyFaces. however inside trinidad/adf the commandLink will not work ... -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] commandLink obsolete ?
The bug is still in the RI (1.1._02) so s:commandLink is not obsolate. the bug in s:commandLink is, that it is not working w/ Trinidad http://issues.apache.org/struts/browse/STR-2966 -M On 10/28/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/28/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: the bug, so can sb apply the patch ? On 10/28/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: wow, it is still there :) What patch? If it's something in the Struts JIRA, add a comment to the issue. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts-Faces] possible Bug in FormRenderer
Hey, two things. a) is this the right place to ask questions on Struts-Faces, or where ? if so b) the demos of struts faces show a portal which uses links (done w/ JSF-components) to navigate to a tiles pages, which finally contains a s:form based formular. that is the key... ActionForm/Action on the java side and JSF comp.s on the page side. Every thing works. A form-submit sends a req. to the action So far so good... When I am converting one of my own apps w/ struts-faces I'd like to stay with html:link for linking to form pages (that are using s:form). But ... since that is a GET request the form renders html like form name=fooForm action=/blub/tilesMasterLayout.do ... (only when using GET / html:link) so ... a submit causes a 404. Not wondering :) When I use firebug to change the action attr value to /blub/tilesMasterLayout.faces every thing works. Action is called. The action() method in FormRenderer returns in the wrong szenario a .do URL I think it is not to bad to check agains a struts pattern in that URL and replace that .do (if needed) with the jsf pattern (like .faces or add /faces/) I think this is valid, because the form renders already fine, which ensures you are inside the FacesContext ... If you all agree, I'd like to provide the patch for that. Greetz, Matt -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts-Faces] commandLink obsolete ?
commandLink was create in 2004, b/c of a RI bug. I guess (or assume) that it has been fixed there. works fine w/ MyFaces. however inside trinidad/adf the commandLink will not work ... -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
Where is lives is less of a concern, but I'd be happy either as a TLP or as part of MyFaces. I'm very glad that Shale was accepted here and given time to grow and develop a community, but I think it's time to find a new home. I'd like to see Struts (the project) return to a focus on building a great Action framework, and let Shale continue to explore what can be done with JSF. yeah, there is some truth in it. But why Shale as a TLP? subproject of MyFaces is a -0 to me. What about a generic Faces project, like portals or ws ? Apache Faces. To me Shale fits fine into that. There - in an apache faces land - is enough space for: Myfaces Tomahawk Tobago Shale Sandbox (well, our sandbox) and soon Trinidad (aka ADF Faces donation) WDYT ? -Matthias -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
To me it makes more sense to have an Apache Faces TLP with lot's of subprojects. MyFaces as TLP is sometimes confusing too. Why all these component libs. For instance you can't mix Tobago with Tomahawk. ... but you can use Tobago with each JSF impl so, hey I am +1 for a Apache Faces TLP and +1 for having Shale its place there in. -Matthias On 6/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: What about a generic Faces project, like portals or ws ? Apache Faces. To me Shale fits fine into that. There - in an apache faces land - is enough space for: Myfaces Tomahawk Tobago Shale Sandbox (well, our sandbox) and soon Trinidad (aka ADF Faces donation) WDYT ? As far as I can tell, you've just proposed adding Shale and renaming the MyFaces project to just 'Faces'. :) Everything you listed (except Shale) is already at MyFaces, or coming soon. And I agree, Shale is a better fit with that list. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standalone Tiles as TLP
That's only because Tomahawk is using Struts Tiles instead of Standalone Tiles, right? right, Shale's TilesViewHandler.java requires the following clazzes of tile-core.jar snip import org.apache.tiles.ComponentContext; import org.apache.tiles.ComponentDefinition; import org.apache.tiles.DefinitionsFactoryException; import org.apache.tiles.NoSuchDefinitionException; import org.apache.tiles.TilesUtil; /snip -Matthias Greg - 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: Standalone Tiles as TLP
think so too,that there is no public tiles-core.jar on any m2 repo, IMO -Matthias -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 4:20 PM To: Struts Developers List Subject: Re: Standalone Tiles as TLP Right but there hasn't been a release of stand alone tiles yet has there? If there are maven jars for standalone then we'll switch now. Sean On 4/21/06, Greg Reddin [EMAIL PROTECTED] wrote: On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote: As for top level project, I agree that Tiles probably belongs here but I'm not opposed. For me the main thing is that Tiles should be decoupled from the Action framework. MyFaces Tomahawk currently requires the full struts jar in order to provide Tiles support. That's only because Tomahawk is using Struts Tiles instead of Standalone Tiles, right? Greg - 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: html taglib autocomplete
I know that autocomplete is a non standard attribute so might not be accepted as a patch on the taglib. But if it only rendered if specified then it wouldn't force users to use non standard stuff. JSF 1.2 goes the same route. The autocomplete attribute has been added to h:inputText / component by Ed Burns. so I am +1 on *patching* Struts' taglib -Matthias If such a patch is likely to make it into future versions I'll get on it. Mark - 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: [Shale] Dialogs
any progress on this right now? -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 31, 2006 7:33 PM To: Struts Developers List Subject: Re: [Shale] Dialogs I attached my clazz to jira. nevermind, bugzilla... http://issues.apache.org/bugzilla/show_bug.cgi?id=38298 -Matthias - 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]
[Shale] Dialog
Hi, a while back, there was a discussion regarding annotation based dialog stuff (started by David or Gary ?). I just found an interesting article about integration of Beehive's PageFlow into JavaServer Faces ([1]). Perhaps interesting for some of you as well. However, some stuff looks similar to Shale's ViewHandler stuff ... :) Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Dialog
Definitely interesting. There are some overlaps with what Shale does, especially in the Shale Tiger Extensions[1] feature that lets you use annotations to register components/converters/validators, define view controllers, and declare managed beans. Right! That was what I was thinking first. But IMHO I like more the Shale way, since you don't need no interface or superclass. You will notice that annotated navigation is not on that list ... and Really ? I have to search my older struts dev email. I am thinking, I have seen something like that in this list. -Matthias philosophically I believe that navigation should *not* be configured that way. But it is certainly something that could be accomplished technically. Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html - 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: [Shale] Dialog
Really ? I have to search my older struts dev email. I am thinking, I have seen something like that in this list. Ok... I found, what I was searching for... http://www.mail-archive.com/dev@struts.apache.org/msg16633.html Making the dialog facility easier by convention over config. You got me :-) I guess I mixed some ideas, since you mentioned the tiger extension... Anyway, the emails are *old* December is long time ago ;-) Regards, Matthias -Matthias philosophically I believe that navigation should *not* be configured that way. But it is certainly something that could be accomplished technically. Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.html - 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: [Shale] Dialogs
I attached my clazz to jira. nevermind, bugzilla... http://issues.apache.org/bugzilla/show_bug.cgi?id=38298 -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r367968 - in /struts/shale/trunk/use-cases/src: java/org/apache/shale/usecases/remoting/ java/org/apache/shale/usecases/view/ web/ajax/ web/validator/
David-
I'll take care this evening of German translations
-Matthias
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 11, 2006 9:31 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r367968 - in
/struts/shale/trunk/use-cases/src:
java/org/apache/shale/usecases/remoting/
java/org/apache/shale/usecases/view/ web/ajax/ web/validator/
Author: dgeary
Date: Wed Jan 11 00:31:12 2006
New Revision: 367968
URL: http://svn.apache.org/viewcvs?rev=367968view=rev
Log:
Localized the first item in the zipcode pull-down menu for
the Ajax form completion example. Localized the links, on the
Ajax form completion and Validator examples, that point back
to the main usecases page. Added appropriate entries to the
French and German properties files, but left the German
values for the new properties in English.
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_fr.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Domains.java
struts/shale/trunk/use-cases/src/web/ajax/zipCode.jsp
struts/shale/trunk/use-cases/src/web/validator/test.jsp
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/remoting/Business.java?rev=367
968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/remo
+++ ting/Business.java Wed Jan 11 00:31:12 2006
@@ -43,7 +43,7 @@
*parameter was put in request scope by an Ajax
call--see zipCode.jsp
*for more details. When the XML response is complete, the
*codeprotected/code method
codeselectItems/code invokes
-*coderesponeComplete()/code on the Faces
context, which ends
+*coderesponseComplete()/code on the Faces
context, which ends
*the response./p
*/
public void cityAndStateForZip() throws IOException { @@
-54,9 +54,8 @@
String zip = (String)requestParams.get(zip);
Domains domains = (Domains) getBean(domains);
- if (zip != null) {
+ if (zip != null)
selectItems(context, domains.getCityAndStateItems(zip));
- }
else
selectItems(context, domains.getBlankCityAndStateItems());
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/view/Bundle.properties?rev=367
968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/view
+++ /Bundle.properties Wed Jan 11 00:31:12 2006
@@ -30,10 +30,10 @@
# Ajax Zip Code Example
ajax.zip.zipWindowTitle=Ajax with Shale Remoting
usecases.ajaxZip=Form completion
-ajax.zip.streetPrompt=Street ajax.zip.cityPrompt=City
ajax.zip.statePrompt=State ajax.zip.zipPrompt=Zip
+ajax.pick=pick one
# JNDI Test Labels
jndi.test.title=JNDI Test Title
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/view/Bundle_de.properties?rev=
367968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/view
+++ /Bundle_de.properties Wed Jan 11 00:31:12 2006
@@ -27,6 +27,14 @@
ajax.completion.finish=Beenden
ajax.completion.submit=Senden
+# Ajax Zip Code Example
+ajax.zip.zipWindowTitle=Ajax with Shale Remoting
usecases.ajaxZip=Form
+Completion ajax.zip.cityPrompt=City ajax.zip.statePrompt=State
+ajax.zip.zipPrompt=Zip Code ajax.pick=pick one
+
# JNDI Test Labels
jndi.test.title=JNDI Test Titel
jndi.test.expected=Erwartet:
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_fr.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
RE: svn commit: r367968 - in /struts/shale/trunk/use-cases/src: java/org/apache/shale/usecases/remoting/ java/org/apache/shale/usecases/view/ web/ajax/ web/validator/
Nevermind,
just filed that ticket!
-Matthias
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 11, 2006 10:21 AM
To: Struts Developers List
Subject: RE: svn commit: r367968 - in
/struts/shale/trunk/use-cases/src:
java/org/apache/shale/usecases/remoting/
java/org/apache/shale/usecases/view/ web/ajax/ web/validator/
David-
I'll take care this evening of German translations
-Matthias
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 11, 2006 9:31 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r367968 - in
/struts/shale/trunk/use-cases/src:
java/org/apache/shale/usecases/remoting/
java/org/apache/shale/usecases/view/ web/ajax/ web/validator/
Author: dgeary
Date: Wed Jan 11 00:31:12 2006
New Revision: 367968
URL: http://svn.apache.org/viewcvs?rev=367968view=rev
Log:
Localized the first item in the zipcode pull-down menu for the Ajax
form completion example. Localized the links, on the Ajax form
completion and Validator examples, that point back to the main
usecases page. Added appropriate entries to the French and German
properties files, but left the German values for the new
properties in
English.
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_fr.properties
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Domains.java
struts/shale/trunk/use-cases/src/web/ajax/zipCode.jsp
struts/shale/trunk/use-cases/src/web/validator/test.jsp
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/remoting/Business.java?rev=367
968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/remoting/Business.java (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/remo
+++ ting/Business.java Wed Jan 11 00:31:12 2006
@@ -43,7 +43,7 @@
*parameter was put in request scope by an Ajax
call--see zipCode.jsp
*for more details. When the XML response is complete, the
*codeprotected/code method
codeselectItems/code invokes
-*coderesponeComplete()/code on the Faces
context, which ends
+*coderesponseComplete()/code on the Faces
context, which ends
*the response./p
*/
public void cityAndStateForZip() throws IOException { @@
-54,9 +54,8 @@
String zip = (String)requestParams.get(zip);
Domains domains = (Domains) getBean(domains);
- if (zip != null) {
+ if (zip != null)
selectItems(context, domains.getCityAndStateItems(zip));
- }
else
selectItems(context, domains.getBlankCityAndStateItems());
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/view/Bundle.properties?rev=367
968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle.properties (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/view
+++ /Bundle.properties Wed Jan 11 00:31:12 2006
@@ -30,10 +30,10 @@
# Ajax Zip Code Example
ajax.zip.zipWindowTitle=Ajax with Shale Remoting
usecases.ajaxZip=Form completion -ajax.zip.streetPrompt=Street
ajax.zip.cityPrompt=City ajax.zip.statePrompt=State
ajax.zip.zipPrompt=Zip
+ajax.pick=pick one
# JNDI Test Labels
jndi.test.title=JNDI Test Title
Modified:
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src
/java/org/apache/shale/usecases/view/Bundle_de.properties?rev=
367968r1=367967r2=367968view=diff
==
---
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecase
s/view/Bundle_de.properties (original)
+++
struts/shale/trunk/use-cases/src/java/org/apache/shale/usecases/view
+++ /Bundle_de.properties Wed Jan 11 00:31:12 2006
@@ -27,6 +27,14 @@
ajax.completion.finish=Beenden
[Shale] Dialogs
Hi Shales, I can start the *dialog* stuff by using h:commandButton action=dialog:Go .../ However, is it possible to a login page (w/ j_security) and after sucessfull login do *forward* to my Go dialog? Or do I have to provide a hello press that button pages *after* a user logs into that application? -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
404 Error for DEV-Documentation
Hi there, When I am on *users* doc (e.g. http://struts.apache.org/struts-action/userGuide/building_view.html#vali dator) and I click on link see the Developers Guide (ref to http://struts.apache.org/struts-action/userGuide/dev_validator.html ) I got a 404 error :( However, is the current maven site no *complete*? Or should I open a bugzilla ticket on that? Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Struts Shale 1.0.0 Quality
Wendy, this issue on Shale has been added recently. http://issues.apache.org/bugzilla/show_bug.cgi?id=38000 -Matthias -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 4:41 AM To: Struts Developers List Subject: Re: [VOTE] Struts Shale 1.0.0 Quality On 12/5/05, Craig McClanahan [EMAIL PROTECTED] wrote: Once you have had a chance to assess to quality of this build, please respond with a vote on the quality: The core-library API docs are missing from the 1.0.0 build. Other than that, I don't see anything that hasn't already been reported. -- Wendy - 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: [VOTE] Struts Shale 1.0.0 Quality
Select Language These behaviors may be nominal (or not) * The German message bundle is incomplete I'll have a look on it, when I am at home -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] New Struts committer: Rich Feit
Welcome Rich, good news on that! ;) Greetings, Matthias -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Sunday, December 18, 2005 10:07 PM To: Struts Developers List Subject: [ANNOUNCEMENT] New Struts committer: Rich Feit Please join me in welcoming Rich Feit as a new Struts committer. Rich is a Beehive committer and PMC member. In addition to being a Struts user for years (Beehive is built on Struts), he has been pivotal in designing and coding Struts Ti, both the initial annotationed Beehive version and the current WebWork merger effort. His experience in Struts migration tools in particular will be key to making Struts Action a success. We look forward to his continued contributions as a committer. Welcome, Rich! PMC vote: 7 +1, non-binding committer votes: 3 +1 Don - 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: Lightweight Skin Framework
Mohan- sounds interesting! Thanks for the paper ;) One question: Why are you using a Struts Plugin (SkinPlugin) instead of ContextListener ? With a context listener your framework is not *tied* to struts. -Matthias -Original Message- From: Mohan Kishore [mailto:[EMAIL PROTECTED] Sent: Thursday, November 24, 2005 4:44 AM To: dev@struts.apache.org Subject: Lightweight Skin Framework http://wiki.cs.uiuc.edu/cs527/DOWNLOAD/MohanKishore%2FCSS+Skin -final.doc As part of my course at UIUC, I have written a CSS Skin pattern - along with a sample implementation. I would like to contribute that to the struts framework. It is relatively independent of the struts library (much like the Tiles framework), but I feel that it would be most useful to the web developers when bundled with Struts. I am aware of a much more powerful framework XKins - but imho, that is an overkill for most applications. My pattern assumes that most web developers already have a CSS file that abstracts the pure presentation elements out of the JSP files. This pattern allows you to provide alternative CSS files in the form of skins. regards, Mohan [PS: please let me know if you want the pattern in a different format] Mohan Kishore 1137 Foster City Blvd, Apt 2 Foster City, CA 94404 [EMAIL PROTECTED] - Yahoo! Music Unlimited - Access over 1 million songs. Try it free. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New Struts Committer: Sean Schofield
wow, congrats sean! -Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Sunday, October 23, 2005 11:18 PM To: Struts Developers List Subject: New Struts Committer: Sean Schofield Please join us in welcoming Sean Schofield as a Struts committer. Sean is an Apache MyFaces committer who also been been working on Struts Shale. Welcome, Sean! .. Now you can apply your own patches! PMC vote: 5 +1, 1 +0 -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New Struts Committer: Laurie Harper
Congrats to Laurie and Greg! -Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Sunday, October 23, 2005 11:17 PM To: Struts Developers List Subject: New Struts Committer: Laurie Harper Please join us in welcoming Laurie Harper as a new Struts committer. Over the last few months, Laurie has made hundreds of helpful posts to our lists. He is the author of the very cool Struts Sidebar ( http://www.zotechsoftware.com/products/struts-sidebar), and Laurie has contributed several patches, including fixes to our unit tests (a thankless job). Welcome, Laurie! .. We're looking forward to many more green bars! PMC vote: 7 +1 (binding), 1 +1 (non-binding) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts 1.3] Using Commons Chains instead of Action(s)
Hi all, I have updated some apps to 1.3, that went pretty smooth :-) (Thanks to the good documentation in wiki!!!) I saw in struts-config DTD that for action element now the attributes catalog and command were introduced. I got a chain of commands to work (partly) w/ 1.3. I now have two questions on working with chains instead of actions. #1 How do I *caculate* the navigation inside of my command? Or do I need something extra? After my chain of commands was executed, I saw a blank page (yes... no ActionForward found ;-)) I have in struts-config something like that: action ...command=myChain catalog=publishCat... forward name=success ... /action Is there a key for the Context object, to tell him success must be used for finding the ActionForward object ? #2 This is more a doubt on accessing formbeans in a command. In my command I did the following to lookup my formBean object (inside execute(Context cxt)): FormularBean fb = (FormularBean) cxt.get(Constants.ACTION_FORM_KEY); //org.apache.struts.chain.Constants this works pretty well, but now my doubt... is this the right way ? Thanks for any hint :-) Best Regards Matthias Weßendorf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Struts 1.3] Using Commons Chains instead of Action(s)
Wolfgang- thanks for your fast anwser. BTW. is there any javadoc for 1.3 published yet? -Matthias -Original Message- From: Wolfgang Gehner [mailto:[EMAIL PROTECTED] Sent: Thursday, October 13, 2005 11:43 AM To: Struts Developers List Subject: Re: [Struts 1.3] Using Commons Chains instead of Action(s) do: ActiionMapping mapping = (ActionMapping) context.get(org.apache.struts.chain.Constants.ACTION_CONFIG_KEY); ActionForward fw = mapping.findForward(forwardName); context.setForwardConfig(fw); Also see my Struts 1.3 dev suite (250MB download) at www.infonoia.com (you need to register). We wrapped the above in our own ActContext class which extends ServletActionContext and has context.setForward(forwardName) We also wrote a DispatchCmd, similar to DispatchAction, but for commands, (so you have event handles like onSave(Act Context)) Also see our Struts 1.3 dev suite including svn to Struts 1.3 (250MB download) to get a head start on 1.3 (need to register to access). at www.infonoia.com community downloads section. Best regards, Wolfgang Gehner Matthias Wessendorf wrote: Hi all, I have updated some apps to 1.3, that went pretty smooth :-) (Thanks to the good documentation in wiki!!!) I saw in struts-config DTD that for action element now the attributes catalog and command were introduced. I got a chain of commands to work (partly) w/ 1.3. I now have two questions on working with chains instead of actions. #1 How do I *caculate* the navigation inside of my command? Or do I need something extra? After my chain of commands was executed, I saw a blank page (yes... no ActionForward found ;-)) I have in struts-config something like that: action ...command=myChain catalog=publishCat... forward name=success ... /action Is there a key for the Context object, to tell him success must be used for finding the ActionForward object ? #2 This is more a doubt on accessing formbeans in a command. In my command I did the following to lookup my formBean object (inside execute(Context cxt)): FormularBean fb = (FormularBean) cxt.get(Constants.ACTION_FORM_KEY); //org.apache.struts.chain.Constants this works pretty well, but now my doubt... is this the right way ? Thanks for any hint :-) Best Regards Matthias Weßendorf - 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.3] Using Commons Chains instead of Action(s)
Wolfgang- I am now doing something like this inside of execute(Context context): ActionContext ctx = (ActionContext) context; ... ActionMapping mapping = (ActionMapping)ctx.getActionConfig(); ActionForward fw = mapping.findForward(success); Since the passed ContextIMPL is ServletActionContext, I think it will be ok... in any environment (portlet e.g) Any comments? -Matthias On Thu, 2005-10-13 at 11:42 +0200, Wolfgang Gehner wrote: do: ActiionMapping mapping = (ActionMapping) context.get(org.apache.struts.chain.Constants.ACTION_CONFIG_KEY); ActionForward fw = mapping.findForward(forwardName); context.setForwardConfig(fw); Also see my Struts 1.3 dev suite (250MB download) at www.infonoia.com (you need to register). We wrapped the above in our own ActContext class which extends ServletActionContext and has context.setForward(forwardName) We also wrote a DispatchCmd, similar to DispatchAction, but for commands, (so you have event handles like onSave(Act Context)) Also see our Struts 1.3 dev suite including svn to Struts 1.3 (250MB download) to get a head start on 1.3 (need to register to access). at www.infonoia.com community downloads section. Best regards, Wolfgang Gehner Matthias Wessendorf wrote: Hi all, I have updated some apps to 1.3, that went pretty smooth :-) (Thanks to the good documentation in wiki!!!) I saw in struts-config DTD that for action element now the attributes catalog and command were introduced. I got a chain of commands to work (partly) w/ 1.3. I now have two questions on working with chains instead of actions. #1 How do I *caculate* the navigation inside of my command? Or do I need something extra? After my chain of commands was executed, I saw a blank page (yes... no ActionForward found ;-)) I have in struts-config something like that: action ...command=myChain catalog=publishCat... forward name=success ... /action Is there a key for the Context object, to tell him success must be used for finding the ActionForward object ? #2 This is more a doubt on accessing formbeans in a command. In my command I did the following to lookup my formBean object (inside execute(Context cxt)): FormularBean fb = (FormularBean) cxt.get(Constants.ACTION_FORM_KEY); //org.apache.struts.chain.Constants this works pretty well, but now my doubt... is this the right way ? Thanks for any hint :-) Best Regards Matthias Weßendorf - 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]
[test] do not answer
Just a ping... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[builds] Re: Struts Ti
Will you guys add Ti to nightly builds? just looked at svn.a.o and saw not archive there. Thanks, Matthias -Original Message- From: Rich Feit [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 5:02 AM To: Struts Developers List Subject: Re: Struts Ti Currently, you can cd into core and run 'maven jar' using Java 1.4. Building the entire project (including the 'java5' module) requires Java 5. Does that sound reasonable? The two modules do currently build to separate jars. Currently the 'samples' module (webapp) is written against the annotations, so it requires Java 5. I think that we should have samples running under both 1.4 and 5. (There's a code layer that can sit on top of annotations (Java 5) and XDoclet (Java 1.4), but I haven't submitted it yet.) Rich Don Brown wrote: That looks about right. It should be possible to run Ti, using xjavadoc tags instead of Java 5 annotations, on Java 1.4. I'd imagine the java5 directory would build into a separate jar or perhaps only be added to a core jar when not labeled as the Java 1.4 version: Java 1.4 version - ti-core-java14-1.0.jar Java 5 version - ti-core-java5-1.0.jar What do you think is best? Don James Mitchell wrote: Ok, so other than requires 1.5 to build, and 1.4 to run via maven prop maven.compile.source=1.4, what else do I need to do? I guess what I'm trying to ask is, what do we want to support? - 1.5 required to: - build from svn checkout - build from nightly src distribution - build from any src distribution - 1.4 required to: - run sample apps - ??? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: callto://jmitchtx On Aug 29, 2005, at 10:29 PM, Don Brown wrote: James Mitchell wrote: Ok, so I'm working on the Maven build scripts, and I have a couple questions. * Why Ti? What does that mean? Titanium. I enjoy ultralight backpacking so titanium is near and dear to my heart as an incredibly strong, very lightweight material used in core gear that replaced much heavier counterparts - the struts of my gear, if you will :) * Why is there a java5 dir? I see ti interface, but why not just put it under core? The java5 dir contains Java 5-specific files, at this point only Java 5 annotations. While Ti will take advantage of Java 5, it shouldn't be required. HTH, Don -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: callto://jmitchtx - 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] - 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: [builds] Re: Struts Ti
thanks! that sounds perfect to me! I guess that statements gets lost inside my *old school* inbox (otlk) 8-) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 2:19 PM To: Struts Developers List Subject: Re: [builds] Re: Struts Ti That was actually on the end of one of the last emails I sent. I fully intend to get make a nightly available before the end of today. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: callto://jmitchtx On Aug 30, 2005, at 5:01 AM, Matthias Wessendorf wrote: Will you guys add Ti to nightly builds? just looked at svn.a.o and saw not archive there. Thanks, Matthias -Original Message- From: Rich Feit [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 5:02 AM To: Struts Developers List Subject: Re: Struts Ti Currently, you can cd into core and run 'maven jar' using Java 1.4. Building the entire project (including the 'java5' module) requires Java 5. Does that sound reasonable? The two modules do currently build to separate jars. Currently the 'samples' module (webapp) is written against the annotations, so it requires Java 5. I think that we should have samples running under both 1.4 and 5. (There's a code layer that can sit on top of annotations (Java 5) and XDoclet (Java 1.4), but I haven't submitted it yet.) Rich Don Brown wrote: That looks about right. It should be possible to run Ti, using xjavadoc tags instead of Java 5 annotations, on Java 1.4. I'd imagine the java5 directory would build into a separate jar or perhaps only be added to a core jar when not labeled as the Java 1.4 version: Java 1.4 version - ti-core-java14-1.0.jar Java 5 version - ti-core-java5-1.0.jar What do you think is best? Don James Mitchell wrote: Ok, so other than requires 1.5 to build, and 1.4 to run via maven prop maven.compile.source=1.4, what else do I need to do? I guess what I'm trying to ask is, what do we want to support? - 1.5 required to: - build from svn checkout - build from nightly src distribution - build from any src distribution - 1.4 required to: - run sample apps - ??? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: callto://jmitchtx On Aug 29, 2005, at 10:29 PM, Don Brown wrote: James Mitchell wrote: Ok, so I'm working on the Maven build scripts, and I have a couple questions. * Why Ti? What does that mean? Titanium. I enjoy ultralight backpacking so titanium is near and dear to my heart as an incredibly strong, very lightweight material used in core gear that replaced much heavier counterparts - the struts of my gear, if you will :) * Why is there a java5 dir? I see ti interface, but why not just put it under core? The java5 dir contains Java 5-specific files, at this point only Java 5 annotations. While Ti will take advantage of Java 5, it shouldn't be required. HTH, Don -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: callto://jmitchtx - 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] - 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
RE: svn commit: r264074 - in /struts/shale/trunk: ./ clay-plugin/ core-library/ test-framework/ use-cases/
SEVERE: Class org.apache.myfaces.component.html.ext.HtmlDataTablePhaseListen er not found java.lang.ClassNotFoundException: org.apache.myfaces.component.html.ext.HtmlDataTablePhaseListener that clazz is not more existing. see: http://www.mail-archive.com/dev@myfaces.apache.org/msg03777.html can you download a *nightly* build ? with the api and impl ?!? -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standalone Tiles - JSP version tld file
Martin- there is also an issue with the Maven build for Tiles standalone. the dtds are not inside the jar file, *after* maven build see here: http://issues.apache.org/bugzilla/show_bug.cgi?id=36096 -Matthias -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 7:44 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Standalone Tiles - JSP version tld file On 8/24/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/24/05, James Mitchell [EMAIL PROTECTED] wrote: Sorry if I'm piping up late on this. What's the plans for Tiles? Will we support embedded tiles or will we simply adapt standalone to work as we do for the commons stuff? That's definitely a call for the developers invested in 1.3.x, but it certainly makes the most sense to have one and only one implementation around, and just do bindings to it. Such bindings should be very easy in this case. My preference would definitely be to support only one version, with that version being the one we expect to support in future releases. So, +1 for supporting Standalone Tiles only. However, I've got a separate / semi-related question. Given that we're changing package names anyway, it would be really cool to abstract away the servlet API specific calling sequences, so that standalone Tiles could work equally comfortably in a portlet environment (without needing any portlet-servlet bridgework). The only API a typical Tiles user will be using is Controller, so this shouldn't be a huge deal. What do you think? I'd say go for it. I would be *very* surprised if any more than a tiny minority of Tiles users have any dependency on the Tiles API at all. In my experience, the vast majority of Tiles users know little more than they need to know to define their tiles in the tiles-defs.xml file. -- Martin Cooper If we're ever going to do this to standalone Tiles, pre-1.0 would seem like the right time. Craig -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote: On 8/24/05, Martin Cooper [EMAIL PROTECTED] wrote: On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (on struts-user) test.jsp has this: %@ taglib uri=http://jakarta.apache.org/tiles; prefix=tiles % Jakarta? That can't be right... there's a problem: The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri, which is coming from src/conf. I noticed that tld the other day when I was changing the Maven build files. The doc/userGuide/tiles-core.xml file does have the right uri. I think the one in src/conf needs to be deleted-- the tld is probably still supposed to be generated from the files under doc/userGuide and doc/ stylesheets as part of the build. Eventually I'll generate a complete tld with all the documentation, so that Maven can create the taglibdoc and tag reference pages... the one in src/conf doesn't have any of that. And what JSP version is Standalone Tiles using? The build files declare a dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that going to be possible with the mismatch in dependencies? I believe the intent was that Standalone Tiles should rely on Servlets 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case, and that we just need to fix up Tiles to conform to that. Yes, that was definitely the intent for Standalone Tiles. It probably got mixed up during the multiple iterations of cut-n-paste from the Struts-embedded sources, plus cut-n-paste changes to the build environment, plus ... Craig -- Martin Cooper -- Wendy - 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,
RE: Standalone Tiles - JSP version tld file
So, with that said, can we move standalone to subproject level or are we waiting on something? A sublevel project of Struts sounds fine, but here is also a proposal from Ted, since Tiles is used by others like Velocity or MyFaces http://wiki.apache.org/struts/TilesTopLevel -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Standalone Tiles - JSP version tld file
ok, fine. :-) I'll look at it, thanks. -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 3:26 PM To: Struts Developers List Subject: Re: Standalone Tiles - JSP version tld file On Aug 25, 2005, at 1:44 AM, Matthias Wessendorf wrote: Martin- there is also an issue with the Maven build for Tiles standalone. the dtds are not inside the jar file, *after* maven build Make sure you're svn copy is up to date. I believe Wendy fixed that. If I run maven jar I get the DTDs in my jar files. Greg - 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: Standalone Tiles - JSP version tld file
fine, I'll close that bug -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 4:17 PM To: Matthias Wessendorf Subject: Re: Standalone Tiles - JSP version tld file From: Matthias Wessendorf [EMAIL PROTECTED] there is also an issue with the Maven build for Tiles standalone. the dtds are not inside the jar file, *after* maven build see here: http://issues.apache.org/bugzilla/show_bug.cgi?id=36096 This was fixed in r239261 on August 22, but not in maven.xml (which was removed). I added a resource to project.xml to get the DTDs into org/apache/tiles/resources. My apologies for not noticing your bug report and crediting you. I did it as part of decoupling Standalone Tiles from the Struts common build files, at which point I just went through and made sure that the Maven build did everything the Ant build does. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: ApacheCon 2005 SanDiego
Craig, My Shale talk got accepted as well. As long as you're scheduled on Monday or Tuesday (I have to fly out on Wednesday) I should be able to join you. Craig Will it be a *tandem* talk with David Geary? -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
ah... were did you read it ?!? Rod Johnson and many others. But, that should be a start to think about, Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
cool to hear that Gary is now on board! Welcome, Gary! -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 2:54 AM To: Struts Developers List Subject: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre Please join me in welcoming Gary vanMatre as a new Struts committer. Gary has been quite busy proposing code for the Clay plug-in on Shale, and has also been supportive on the dev and user mailing lists (for both Struts and MyFaces) ... we look forward to his energy being available to the entire Struts project as well. Welcome, Gary! (And now you can process some of your own outstanding code diffs :-). PMC vote: 4 +1 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]
RE: {Spam?} Re: New Shale Regex Validation Tag
Gary,
that looks nice!
Haven't looked at Clay yet, only Faclets...
.Matthias
Clay would work very well to spice up the client view. As
for the XML configuration:
component jsfid=commonsValidator
componentType=org.apache.shale.ValidatorScript/
component jsfid=firstNameRegExp extends=commonsValidator
attributes
set name=arg value=#{msg.firstName}/
set name=server value=true
set name=client value=true
set name=type value=mask
set name=mask value=#{regex.firstName}
/attributes
/component
And, the JSP:
clay:clay id=regexValidator jsfid=firstNameRegExp/
Gary
david
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: New Shale Regex Validation Tag
Ron,
have you looked at:
http://myfaces.apache.org/tomahawk/validateRegExpr.html
-Matthias
-Original Message-
From: Romero, Ron [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 6:10 PM
To: Struts Developers List
Subject: New Shale Regex Validation Tag
I'm working with the Shale Validator. I would like a new, simpler
regexValidator tag that better supports my situation (and hopefully
supports other people's situation).
BACKGROUND
==
We're writing a JSF Portlet app. The *only* part of Shale that we're
using is the Validator. We're using only the Regex package, and we
always want client-side and server-side validation.
We will provide the regexes for the entire project in a
single place, so
that, for example, run-of-the-mill developers don't have to decide how
many and which characters are allowed in a first name. And so we can
change the firstName regex in a single place and effect the
entire app.
Our current approach is to put all of the regexes into a
message bundle,
and instruct users to use the message bundle to specify their regular
expression. So current usage looks like this:
s:commonsValidator arg=#{msg.firstName}
server=true client=true
type=mask mask=#{regex.firstName} /
THE NEW REGEX TAG
=
I would like to have a general tag where the developer specifies the
type of field, and the field looks up the regex needed, and possibly
also whether verification should be client-side or server-side or both
and possibly also the arg to use in the error message. Using this I
would like to the tag to be very simple to use. The above usage would
look like this:
s:regexValidator type=firstName /
Validator masks and information would be stored in a
configuration file,
maybe validator-regexes.xml
WHAT TO DO
==
This would involve writing a new custom tag. It would look up the
relevant information, and then call Shale commonsValidator with that
information. This would all be in Shale Validator; we don't need any
new functionality from commons-validator.
I may be able to write the code for this, or primarily write the code.
And I can definitely test, debug, and suggest. But, frankly, it's not
worth my trouble to work on this unless it'll get back into Shale
Validator.
So, what do you think? Is this worthwhile? Any major holes? Is this
something Shale Validator should be doing? Should I enter a bugzilla
enhancement request?
Thanks,
Ron Romero
Texas ACCESS Alliance
Work 512-732-5827
AIM: ronzromero
[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: JSF vs. Struts
is currently in, what I would call, a state of exploration. In addition to Shale and Ti, there are other projects like Struts Overdrive, Struts Flow, etc., which are also exploring different aspects of web development. Of course, there will be Struts classic still for a long time to come which will continue to forego active development. I think Struts is realizing there is no one way when it comes to web development. If a particular project or approach interests you, join in. Personally, I think shale will be a great success building on the strong JSF framework, and if it meets your needs, give it a shot. Just as not every web application is the same, neither is their needs for a framework. Don On 8/10/05, James Mitchell [EMAIL PROTECTED] wrote: Those of you on the Struts Developers list. Would you like to comment on this? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: Matthias Wessendorf [EMAIL PROTECTED] To: MyFaces Discussion users@myfaces.apache.org; [EMAIL PROTECTED] Sent: Wednesday, August 10, 2005 7:29 AM Subject: Re: JSF vs. Struts currently the are *forking* :) Struts Ti see here: http://www.opensubscriber.com/message/dev@struts.apache.org /1854691.html and Shale (aka Struts 2.0) is build on top of JSF. It is a framework for JSF ... On 8/10/05, Werner Punz [EMAIL PROTECTED] wrote: Doing both, I only can recommend, if you can omit struts and go directly for MyFaces (not the JSF RI, it lacks severely) Struts feels somewhat dated in many areas compared to JSF. Werner Aleksei Valikov wrote: Hi. Could anyone post a good link on Struts vs. JSF comparison? I have a meeting in 40 minutes where I need to push through my decision on using JSF for a large project (GIS/Map Viewers). Seems like I can argument my decision, but some additional support material would be helpful. Thanks in advance. Bye. /lexi -- Matthias Wessendorf --- -- 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] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Tiles] Struts Plugin in standalone Tiles
btw. I just looked at the binary jar file (after runing maven; not ant) and saw,
that there is no o.a.t.resources *folder* inside.
in $SRC the XmlParser.java says:
protected String registrations[] = {
-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN,
/org/apache/tiles/resources/tiles-config_1_1.dtd,
-//Apache Software Foundation//DTD Tiles Configuration 1.2//EN,
/org/apache/tiles/resources/tiles-config_1_2.dtd,
};
I added a patch to bugzilla (#36096)
http://issues.apache.org/bugzilla/show_bug.cgi?id=36096
-Matthias
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Monday, August 08, 2005 5:53 PM
To: Struts Developers List
Subject: Re: [Tiles] Struts Plugin in standalone Tiles
On 8/8/05, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yes, the intention is to keep standalone Tiles completely separate
from Struts. The plugin and request processor should be in Struts,
not standalone Tiles.
ok I see, but Tiles currently depends on Struts ... ;)
Here's a spot where naming things precisely is going to be important.
Historically (since Struts 1.1) a version of Tiles (in package
org.apache.struts.tiles) that is integrated with, and dependent on,
Struts has been included. There is a current effort in the Struts
Sandbox to create a *Standalone* version of TIles (in package
org.apache.tiles) that has no such dependencies, and would be more
easily used in other projects like MyFaces and Shale. If you guys
would like to help make that happen (either in the Struts sandbox, or
possibly (thinking out loud) in a separate Jakarta subproject), it
would be great.
The current sandbox code has nightly builds available:
http://cvs.apache.org/builds/struts/nightly/sandbox/tiles-core/
and works with Shale already. The code was a direct port from the
current Struts 1.3.x trunk (well, as of a week or so ago, but there
haven't been any Tiles changes), adding a standalone TilesServlet for
initialization and removing the Struts dependencies.
Beyond just the port, I would also like us to consider remodelling the
standadlone Tiles APIs to work better in a portlet environment (right
now, there's a lot of passing HttpServletRequest and
HttpServletResponse objects around). We could take advantage of the
opportunity to break backwards compatibiltiy on the internal APIs and
fix this too.
-Matthias
Craig
david
Greg
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Tiles] Struts Plugin in standalone Tiles
Hi guys, Is it possible to *use* Apache Tiles (standalone one) inside of Struts 1.2 ? I didn't see a plugin inside of the tiles standalone dist. thx, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Tiles] Struts Plugin in standalone Tiles
Yes, the intention is to keep standalone Tiles completely separate from Struts. The plugin and request processor should be in Struts, not standalone Tiles. ok I see, but Tiles currently depends on Struts ... ;) -Matthias david Greg - 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]
[Sandbox / Tiles] jar files
Hi, are there currently plans to move Tiles out of Struts' sandbox? Will the Tiles jars be published inside of ibiblio repository? Thx. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] ApacheCon Europe
Hi all, perhaps this question has been asked allready, but let me ask it again... Is anybody in Stuttgart (Germany) at ApacheCon Europe 18-22 July. Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Dialog stuff
Since lot's of MyFaces users are also interessted in Shale, I posted that mail/question to both of the lists... so both MyFaces/Shale and Struts/Shale community benefit from that. -mw- Dakota Jack wrote: I have noticed that there is a lot of cross-posting to MyFaces and Struts. Is that an exception in the rules, or do I not understand the difference. I am not trying to start anything but just trying to get some grasp of what the rules are, since I have had a difficult time figuring out what they are. Thanks for any clarity on this. Jack On 4/23/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/23/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Craig, I just noticed that you changed the dialog stuff in Shale, like you suggested a time before. Yep :-). Also I saw that the DialogController clazz is now deprecated. So, can you publish a new version of the JavaDoc of Shale? That would be nice ;) Excellent idea! I've updated the pointers on the Wiki page: http://wiki.apache.org/struts/StrutsShale to today's javadocs for the core library, the experimental clay plug-in, a test framework for building unit tests for Shale-based applications, and the Use Cases example app that shows off the various features. In particular, the logon and edit profile dialogs (of the use cases app) have been modified to use the new dialog mechanism. The package javadocs for the org.apache.shale.dialog package (in the Core Library section) have a fairly extensive discussion on the new concepts. Other interesting recent additions: * The Clay plug-in, for reusable trees of components (reuse on a finer grained scale than pages or fragments) * David Geary and Cay Horstmann have generously contributed the code from Core JavaServer Faces that integrates with Commons Validator. * Integration of Spring's dependency injection framework into the JavaServer Faces managed beans capability (so you can configure beans with Spring but access them through value binding expressions in JSF) regards, matthias Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Dialog stuff
Hi Craig, I just noticed that you changed the dialog stuff in Shale, like you suggested a time before. Also I saw that the DialogController clazz is now deprecated. So, can you publish a new version of the JavaDoc of Shale? That would be nice ;) regards, matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website Location
Don, I had the same last days for myfaces.apache.org but now my changes are online. HTH, Matthias Martin Cooper wrote: You're probably just falling foul of the infra-thon activities. There have been a lot of infra changes this weekend, including failovers and DNS changes. Things should settle down tomorrow. -- Martin Cooper On Mon, 21 Mar 2005 22:26:51 -0800, Don Brown [EMAIL PROTECTED] wrote: What server runs our Struts site now? I used to ssh into svn.apache.org and deploy to www/struts.apache.org, but that doesn't see to be it now, or at least, the new files weren't accessible. Thanks, Don - 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: [OT] ApacheCon Europe2005 - Struts / Shale
Hi Duncan, since there was no answer, so I guess not :-( -Matthias Duncan Mills wrote: Did anyone ever submit a Shale Paper for ApacheCon? Matthias Wessendorf wrote: Hi, I am about to submit a draft regarding JSF and Apache MyFaces. The ApacheCon Europe is this year in Germany (Stuttgart) -- http://www.apachecon.com/2005/EU/index.html/e=MjAwNS9FVQ So now I'm wondering if there is someone how plans to submit (or still has submitted) a draft about Struts or even Shale? Would be interessting to know :-) Regards, Matthias - 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: svn commit: r158315 - in struts/shale/trunk/core-library: build.properties.sample build.xml src/java/org/apache/shale/spring/ src/java/org/apache/shale/spring/WebApplicationContextVariableResolver.java src/java/org/apache/shale/spring/faces-config.xml src/java/org/apache/shale/spring/package.html
Wow. I must find time to get back to Shale. Please announce when Shale +
Tile is ready. Before JavaOne?
Perhaps, seams like David Geary is active on something like that:
http://www.jroller.com/comments/dgeary/Weblog/shale_cometh
Also he holds a talk on Shale @JavaOne:
http://www.jroller.com/page/dgeary/20050319#shale_the_next_struts_at
-Matthias
BaTien
DBGROUPS
Added:
struts/shale/trunk/core-library/src/java/org/apache/shale/spring/
struts/shale/trunk/core-library/src/java/org/apache/shale/spring/WebApplicationContextVariableResolver.java
struts/shale/trunk/core-library/src/java/org/apache/shale/spring/faces-config.xml
struts/shale/trunk/core-library/src/java/org/apache/shale/spring/package.html
Modified:
struts/shale/trunk/core-library/build.properties.sample
struts/shale/trunk/core-library/build.xml
Modified: struts/shale/trunk/core-library/build.properties.sample
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/build.properties.sample?view=diffr1=158314r2=158315
==
--- struts/shale/trunk/core-library/build.properties.sample (original)
+++ struts/shale/trunk/core-library/build.properties.sample Sat Mar 19
23:18:50 2005
@@ -37,6 +37,13 @@
# Jakarta Commons Digester library
digester.home = /usr/local/commons-digester-1.6
+# The absolute or relative pathname of the JavaServer Faces +#
implementation
+jsf.home = /usr/local/jsf-1_1_01
+
+# The absolute or relative pathname of the JUnit 3.8.1 JAR
+junit.home = /usr/local/junit-3.8.1
+
# The absolute or relative pathname of the directory containing the
# Jakarta Commons Logging library
logging.home = /usr/local/commons-logging-1.0.4
@@ -45,13 +52,11 @@
# Servlet API classes JAR file (servlet.jar)
server.home = /usr/local/jakarta-tomcat-5.0.28
-# The absolute or relative pathname of the JavaServer Faces -#
implementation
-jsf.home = /usr/local/jsf-1_1_01
+# (OPTIONAL) The absolute or relative pathname to the dist directory
+# of the Spring Framework distribution (version 1.1.5 or later)
+spring.home=/usr/local/spring-framework-1.1.5/dist
# The absolute or relative pathname of the Apache Struts # distribution
struts.home = /usr/local/jakarta-struts
-# The absolute or relative pathname of the JUnit 3.8.1 JAR
-junit.home = /usr/local/junit-3.8.1
Modified: struts/shale/trunk/core-library/build.xml
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/build.xml?view=diffr1=158314r2=158315
==
--- struts/shale/trunk/core-library/build.xml (original)
+++ struts/shale/trunk/core-library/build.xml Sat Mar 19 23:18:50 2005
@@ -41,7 +41,7 @@
property name=logging.home
value=/usr/local/commons-logging-1.0.4/
property name=server.home
value=/usr/local/jakarta-tomcat-5.0.28/
property name=shale-test.home
value=${basedir}/../struts-shale-test/dist/
-
+ property name=spring.home
value=/usr/local/spring-framework-1.1.5/dist/
!-- Dependency library defaults --
property name=commons-beanutils.jar
@@ -66,16 +66,10 @@
property name=junit.jarvalue=${junit.home}/junit.jar/
property name=servlet-api.jar
value=${server.home}/common/lib/servlet-api.jar/
property name=shale-test.jar
value=${shale-test.home}/lib/shale-test.jar/
-
-
- !-- Conditional Processing Flags --
- available property=jsfri.present
-classname=com.sun.faces.RIConstants
-classpath=${jsf-impl.jar}/
- available property=myfaces.present
-
classname=net.sourceforge.myfaces.config.MyfacesConfig
-classpath=${jsf-impl.jar}/
-
+ property name=spring-context.jar
+
value=${spring.home}/spring-context.jar/
+ property name=spring-core.jar
value=${spring.home}/spring-core.jar/
+ property name=spring-web.jar
value=${spring.home}/spring-web.jar/
!-- Build Defaults --
property name=build.home value=${basedir}/target/
@@ -112,6 +106,9 @@
pathelement location=${jsf-api.jar}/
pathelement location=${jsp-api.jar}/
pathelement location=${servlet-api.jar}/
+pathelement location=${spring-context.jar}/
+pathelement location=${spring-core.jar}/
+pathelement location=${spring-web.jar}/
pathelement location=${build.home}/classes/
/path
@@ -133,10 +130,31 @@
pathelement location=${junit.jar}/
pathelement location=${servlet-api.jar}/
pathelement location=${shale-test.jar}/
+pathelement location=${spring-context.jar}/
+pathelement location=${spring-core.jar}/
+pathelement location=${spring-web.jar}/
pathelement location=${build.home}/classes/
pathelement location=${build.home}/test-classes/
/path
+ !-- Conditional Processing Flags --
+ available property=jsfri.present
+
Re: [Shale] subview component XML composition extension
David- Oops, I forgot. I do have a tiles view handler. I used the MyFaces view handler as a basis for mine, but I did things a little differently. ah, fine! Have you thought about a NavigationHandler? I found it usefull to use tiles definitions inside struts-config.xml for ActionForwards. I guess it should be possible to have a NavigationHandler that enables you to have something like: navigation-case from-outcomesuccess/from-outcome to-view-idmyTilesDefinition/to-view-id /navigation-case -Matthias david -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] subview component XML composition extension
David, No, I don't have anything JSF-specific. The extracted version is simply decoupled from Struts. Otherwise, it's just vanilla Tiles, except that I So you have no facility like a ViewHandler or something like that? Have you looked at MyFaces' TilesViewHandler ? -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] usecases app
David,
Those methods are probably too generally useful to restrict to view
controllers. View controllers are not the only objects that need to
retrieve managed beans, for instance. A utility class might be a better
choice.
Good hint with the Utilclazz. The getBean() is indeed a candiate for it.
But why get getFacesContext()?
It only wrappes FacesContext.getCurrentInstance()
A posible first raw util class could be
snip
package org.apache.shale;
import javax.facex.FacesContext
public final class ShaleUtil{
private ShaleUtil(){}
public static Object getBean(String name) {
FacesContext context = FacesContext.getCurrentInstance();
return context.getApplication().getVariableResolver().
resolveVariable(context, name);
}
}
/snip
Matthias
david
Any idea?
Thanks,
Matthias
-
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]
--
Matthias Weßendorf
Aechterhoek 18
DE-48282 Emsdetten
Germany
phone: +49-2572-9170275
cell phone: +49-179-1118979
email: matzew AT apache DOT org
url: http://www.wessendorf.net
callto://mwessendorf (Skype)
icq: 47016183
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] usecases app
David,
Good hint with the Utilclazz. The getBean() is indeed a candiate for it.
But why get getFacesContext()?
It's also a general utility method.
ah... ;)
It only wrappes FacesContext.getCurrentInstance()
Yes, it seems a bit silly, but the getFacesContext method is there for
folks that don't know about FacesContext.getCurrentInstance().
ok...
second raw version below...
what about helper method regarding value/method binding creation?
eg
public static Object getValueBindingValue(String valueBinding){
FacesContext context = getFacesContext();
return context.getApplication().
createValueBinding(valueBinding).getValue(context);
}
I guess a silly name... getValueBindingValue() ;)
class code here
snip
/*
* Copyright 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 may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.shale;
import java.util.Map;
import javax.faces.context.FacesContext;
/**
* @author a href=mailto:[EMAIL PROTECTED]Matthias Weßendorf/a
*/
public final class ShaleUtil {
private ShaleUtil(){}
public static Object getBean(String name) {
FacesContext context = getFacesContext();
return context.getApplication().getVariableResolver().
resolveVariable(context, name);
}
public static FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
public static Map getSessionMap(){
FacesContext context = getFacesContext();
return context.getExternalContext().getSessionMap();
}
public static Map getRequestMap(){
FacesContext context = getFacesContext();
return context.getExternalContext().getRequestMap();
}
public static Object getValueBindingValue(String valueBinding){
FacesContext context = getFacesContext();
return
context.getApplication().createValueBinding(valueBinding).getValue(context);
}
}
/snip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Struts 1.1
Hi, is there any location I can download Struts 1.1 ? On s.a.o there is only 1.2 downloadable. Thanks! Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
solved (Re: Struts 1.1)
Ok... I found nightly builds of struts-faces... that contains 1.1 Matthias Wessendorf wrote: Hi, is there any location I can download Struts 1.1 ? On s.a.o there is only 1.2 downloadable. Thanks! Matthias - 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]
[OT] Wiki links
Hi, I added a *link* to http://wiki.apache.org/struts/StrutsResources (StrutsELearning) But wiki doesn't generate a link to that corresponding URL (http://wiki.apache.org/struts/StrutsELearning) Did I miss something? Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] ApacheCon Europe2005 - Struts / Shale
Hi, I am about to submit a draft regarding JSF and Apache MyFaces. The ApacheCon Europe is this year in Germany (Stuttgart) -- http://www.apachecon.com/2005/EU/index.html/e=MjAwNS9FVQ So now I'm wondering if there is someone how plans to submit (or still has submitted) a draft about Struts or even Shale? Would be interessting to know :-) Regards, Matthias -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany email: matzew AT apache DOT org url: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WML RenderKit (was RE: Adding mobile tags to Struts Faces)
Michael, sure this thread is old, but I just remember by reading your Shale post :) However, a WML RenderKit is now available in Apache MyFaces. Perhaps you'll take a look at it. TLD: http://incubator.apache.org/myfaces/tlddoc/ files incl. examlpe: http://cvs.apache.org/dist/incubator/myfaces/builds/ Regards, Matthias -Original Message- From: Michael Rassmussen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 3:33 PM To: Struts Developers List Subject: Re: Adding mobile tags to Struts Faces I am not...but I would like to in the near future. On Tue, 6 Jul 2004 07:41:56 +0200, Matthias Wessendorf [EMAIL PROTECTED] wrote: Michael, are you working on a WML-RenderKit ? perhaps you can add this feature to MyFaces? (www.myfaces.org) it is now under Apache2.0-license, since its incubation to apache (http://wiki.apache.org/incubator/MyFacesProposal) cheers, -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 2:40 AM To: Struts Developers List Subject: Re: Adding mobile tags to Struts Faces Michael Rasmussen wrote: Sorry if this comes thru as an HTML post. This is my first post to the list. Let me know if it is a problem. I have been using struts for a while now and really like it. I have also used asp.net and really like some of the features in the ms framework. I am excited at the prospect of JSF bringing these features to JSP/Java. One thing I really think is missing is support for mobile profiles. (Cell phones/wap/pda's) I think struts faces would be a great place to try to put some of that together. I am interested in doing this and wondering how to go about getting set up and if there are others interested. Michael --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Michael, This response is very late (I've been too busy for words lately). But I would recommend that mobile profiles as you describe would make a good candidate for a stand-alone library of pure JavaServer Faces components and renderers ... they need not be tied to Struts, as they would be if included in struts-faces directly. The only thing that should be in struts-faces (IMHO) is bindings to tie the two frameworks together, plus a few tags to make the transition easier for existing Struts based apps -- and one could easily argue that even those should be separated from the core integration library. Craig McClanahan - 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]
RE: WML RenderKit (was RE: Adding mobile tags to Struts Faces)
is old, but I just remember by reading your Shale post :) However, a WML RenderKit is now available in Apache MyFaces. Perhaps you'll take a look at it. TLD: http://incubator.apache.org/myfaces/tlddoc/ files incl. examlpe: http://cvs.apache.org/dist/incubator/myfaces/builds/ Regards, Matthias -Original Message- From: Michael Rassmussen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 3:33 PM To: Struts Developers List Subject: Re: Adding mobile tags to Struts Faces I am not...but I would like to in the near future. On Tue, 6 Jul 2004 07:41:56 +0200, Matthias Wessendorf [EMAIL PROTECTED] wrote: Michael, are you working on a WML-RenderKit ? perhaps you can add this feature to MyFaces? (www.myfaces.org) it is now under Apache2.0-license, since its incubation to apache (http://wiki.apache.org/incubator/MyFacesProposal) cheers, -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 2:40 AM To: Struts Developers List Subject: Re: Adding mobile tags to Struts Faces Michael Rasmussen wrote: Sorry if this comes thru as an HTML post. This is my first post to the list. Let me know if it is a problem. I have been using struts for a while now and really like it. I have also used asp.net and really like some of the features in the ms framework. I am excited at the prospect of JSF bringing these features to JSP/Java. One thing I really think is missing is support for mobile profiles. (Cell phones/wap/pda's) I think struts faces would be a great place to try to put some of that together. I am interested in doing this and wondering how to go about getting set up and if there are others interested. Michael --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Michael, This response is very late (I've been too busy for words lately). But I would recommend that mobile profiles as you describe would make a good candidate for a stand-alone library of pure JavaServer Faces components and renderers ... they need not be tied to Struts, as they would be if included in struts-faces directly. The only thing that should be in struts-faces (IMHO) is bindings to tie the two frameworks together, plus a few tags to make the transition easier for existing Struts based apps -- and one could easily argue that even those should be separated from the core integration library. Craig McClanahan - 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] - 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: Use Cases Example Webapp for the Shale proposal
Jack, it is nice that you like to enlarge MyFaces :-) But I think it's good to see Shale as a framework for JSF, like Struts is a framework for Servlet/JSP (aka Model2). So would it be good to host Struts @ Tomcat folks? Only why it is a *servlet-framework* ? Something like Struts is beyond the scope of Servlet-Spec. The same with Shale. Shale isn't a implementation of JSF spec. It is a framework on top of the spec. Regards, Matthias -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 04, 2005 7:46 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Use Cases Example Webapp for the Shale proposal Whatever happened to the proposals to move this JSF implementation to MyFaces? That would seem to be much more appropriate. Perhaps it could be called JSFShale or FacesShale? What this has to do at all with Struts has never, in my opinion, been explained, beyond the desire to appropriate the Struts name. Jack On Mon, 3 Jan 2005 20:50:12 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: (Cross posting because this topic has come up on all of the lists in the last couple weeks.) I just committed into the Struts SVN repository a new example application (struts-shale-usecases) that illustrate's the different take that Shale has on how an application framework can be built around JSF, including support for dialog scope (longer than a request, but shorter than a session). I've updated the Shale wiki page to contain pointers to the latest API documentation for both Shale and the example app: http://wiki.apache.org/struts/StrutsShale and nightly builds of the example app will be available starting tonight (pointer is on the Wiki page above). The commit message was over the max size allowed, so here's the descriptive text: -- -- Initial commit of an example application for Shale, illustrating more interesting features than one sees with MailReader. In particular: * Use of application level controller features to filter out direct requests for JSP and JSPF (JSP fragment) resources, since they should only be accessed via *.faces URLs. See src/web/WEB-INF/chain-config.xml for configuration of this application's additions to the standard Shale processing chain. * Use of DialogController for a sophisticated workflow with multiple entries and exits: logon dialog for a portal-type site that supports creating new profiles (with or without an email confirmation), plus remember me cookies. See the javadocs for package org.apache.shale.usecases.logon for an overview of this functionality, plus an activity diagram describing the state transitions. (The diagram was produced with Poseidon for UML Community Edition, version 3.0, and the Poseidon project file is also checked in). * Use of standard JSF facilities to support a language picker, based on the supported locales for the application. (NOTE - at present switching languages does not appear to do anything, but that is because I only checked in the default (English) properties file -- if someone would like to translate src/java/org/apache/shale/usecases/view/Bundle.properties into other languages, I'd be happy to check it in. See src/web/locale/select.jsp for the JSP page that does this, and src/java/org/apache/shale/usecases/locale/Select.java for the corresponding backing bean. * Use of managed-property elements to configure the properties of a newly created managed bean, using either literal values or expressions (essentially an example of IoC with setter injection). In this example, such properties are used to: - Configure the DAO object that is used by the business logic of the application, using - Configure the functionality of the DialogController instance, describing whether email confirmations and remember me cookies should be enabled or not. See src/web/WEB-INF/faces-config.xml for configuration of this feature. * General purpose domains object (cached in application scope the first time it is accessed) to provide localized lists of SelectItem value/label pairs (these provide the content for dropdown lists etc.). See src/java/org/apache/shale/usecases/util/Domains.java The Javadocs for this application will be published soon, with a pointer on the Wiki, and nightly builds will commence this evening. -- -- Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Basic workflow engine
and I also saw one workflow engine at Jakarta: http://jakarta.apache.org/commons/sandbox/workflow/ :) -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Friday, December 31, 2004 8:21 AM To: Struts Developers List; Michael Rasmussen Subject: Re: Basic workflow engine This one is super, Michael. Thanks! Jack On Thu, 30 Dec 2004 12:54:16 -0600, Michael Rasmussen [EMAIL PROTECTED] wrote: Just to add to the list of general tools out there for workflow I think this one is fairly nice, though I haven't really used it extensively...works with JSF too Craig http://wfnm.sourceforge.net Michael On Thu, 30 Dec 2004 10:25:52 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 30 Dec 2004 10:18:54 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 30 Dec 2004 12:47:04 -0500, Sean Schofield [EMAIL PROTECTED] wrote: I have developed a basic workflow engine that I have found to be extremely useful in my current Struts applications. I developed it after finding shortcomings in the open source workflow stuff that was available at the time. As you think about workflow, don't forget to keep an eye on a new Apache Incubator project called Agila, which bills itself as a lightweight BPM engine and auxiliary services. There's no code yet, so it's not possible to tell if it will meet your needs, but worth a bookmark for future reference: http://incubator.apache.org/projects/agila/index.html I'm also curious if you looked at Don's continuations support (based on the same idea in Cocoon) in Struts Flow. http://struts.sourceforge.net/struts-flow/index.html Also, if you're using JDK 5, Apache Beehive's Page Flow: http://incubator.apache.org/beehive/pageflow/pageflow_overview.html -- Martin Cooper I know Craig mentioned a possible need for workflow stuff for Shale. I'm not sure if its along the lines of what he is interested in as I have not had the time to delve into Shale yet. So far, I'm developing some ideas and design patterns around state information that is saved longer than a request, but shorter than a session -- and gracefully managing the associated pages and corresponding view controllers. It's not quite ready for the rest of the world to look at yet, but will be soon. In a nutshell, it provides a simple and flexible framework for implementing workflows. It has states, operations, conditions and transitions. It provides a default implementation that writes to a database (but that is not required.) I am currently refactoring it to make it a little easier to be used by others (borrowing from some of the structural ideas I've seen used in commons-chain). I'd be happy to share it for anyone who might want to examine/borrow the code. Also, I'm interested in possibly taking it open source (perhaps as commons-sandbox first.) Let me know if anyone is interested in working with me on this. I'd be interested in seeing what you've come up with. sean 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] -- -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - 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
RE: Taglibs and Tiles Extraction Issues
That a community and its codebase lives is more important than where it lives. Yes, that's it! And also it is important, to have one place where it lives! Not much different. So I would be happy to move the JSF TilesViewHandler from MyFaces to that (new) repository. -Ted. - 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: Shale for 2.x? (was Re: RoadMap)
Hi Ted and others, Objectively, I think that Shale would be a better fit for Apache MyFaces. Uh, interessting point. I read the Shale proposal and found it nice. I haven't tried it for now. Back in the day, it might have been better if we had placed most of our taglibs with Jakarta Taglibs, rather than keep them all here. I think this is the same sort of thing. I guess that was before my time here ... :-) Since I'm not doing the work, I can't make the decision, but I think it would be nice if a serious proposal were made to Apache MyFaces before launching Shale from here. Shale has been mentioned on the MyFaces lists a couple of times, but no one has asked the question Do we want to host Shale here at Apache MyFaces?. Well, I allways thought it is a Struts thing. One alternative solution to the Jericho/Chain issue... Or even including more standards, since Filters where mentioned in Shale... Apache MyFaces already has generic JSF components, and Shale fits in that venue. They also have a very strong JSF community that can appreciate, support, and enhance Shale. We have some extra components in MyFaces. Custom validators based on Commons Validator. Now I am about to include a RenderKit for WML. Also support for Tiles see: http://www.apache.org/~matzew/myfaces-tiles-example.war Perhaps we could bring the MyFaces' TilesViewHandler to David's comming Tiles project. BTW. I would like to see this project inside of Apache ... But I am now becomming OT... I guess the Struts developers should decide what they wanted to do with Shale (and Tiles). Just my thought. Regards, Matthias Eventually, if everyone migrates to Shale, and the Struts community withers away, then so be it. Let Darwin decide. -Ted. On Wed, 29 Dec 2004 10:50:42 -0800, Craig McClanahan wrote: On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted [EMAIL PROTECTED] wrote: Is there anything someone would like put differently? I'm somewhat curious when the Struts committers might be willing to make a conscious choice for a Struts 2.x architecture. While I'm personally going to continue to support the 1.3.x changes for evolution of existing apps, and use of the Struts-Faces integration library with it, I believe that Struts will become gradually less relevant for new application development unless it adopts JSF strongly; and it would be a shame to have to *compete* with Struts instead of *being* Struts. -Ted. 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: Taglibs and Tiles Extraction Issues
David, are you thinking about bringing Tiles up to incubator ? To be a *toplevel* apache project like Struts itself? And yes... Merry Christmas ;-) Matthias -Original Message- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Saturday, December 25, 2004 6:39 PM To: Struts Developers List Subject: Re: Taglibs and Tiles Extraction Issues Merry Christmas, btw! Le Dec 25, 2004, à 1:35 AM, Don Brown a écrit : I don't know about the other Struts folks, but I think this is would be a great addition to Tiles. This is not an addition to Tiles, this *is* Tiles. Perhaps I wasn't clear. I have extracted the Tiles code from Struts 1.1, including the taglibs. I have taken that code and added a few enhancements, including a Tiles servlet, a JSF view handler and some demos. I have a standalone version of Tiles that works without Struts. Initially, the Struts Tiles subproject could host Tiles, but as more adapters get added, and perhaps the Tiles community enlarges, there would be enough interest in hosting the Tiles project somewhere outside of Struts. It seems to me that now is the time for Tiles to be it's own project. Tiles has nothing to do with Struts, other than the fact that it provides Struts integration. With my version of Tiles, I'd like to provide integration for other display technologies as well. I'm also interested in exploring integration with SiteMesh, which is a neat technology (for page decoration) that compliments Tiles (for page composition) nicely. None of those goals for Tiles has anything to do with Struts. I also think that Tiles would get more attention if it were it's own project instead of a Struts subproject. IMO, Tiles has stagnated and is due for a facelift. david As for adapters, the Tiles build could follow the pattern commons-chain uses to optionally build adapters as jars are available. Let me get the Tiles subproject setup, then we can start working on integrating this code. Don David Geary wrote: I have extracted a standalone version of Tiles from Struts 1.1. I've implemented a TilesServlet for using Tiles outside of Struts and a JSF view handler that forwards to a tile instead of a JSP page. I also have some cool examples. I was on the verge of starting an open source project for standalone Tiles that would focus on integration with other presentation technologies besides Struts, such as JSF, Velocity, Tapestry, etc. I want a Tiles version that I can use with JSP only, or with the framework of my choice. And I want Tiles to be integrated as smoothly as possible with my framework. I don't want to have to drag Struts around to do that. So, I'm not sure what to do with my code. Do my goals for a standalone Tiles align with the goals for the Tiles subproject within Struts? david Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit : On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown [EMAIL PROTECTED] wrote: I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on. 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy this method over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that subprojects will be bundled with Struts releases ala Linux distributions, but how do we communicate intra-subproject dependencies? The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the code within Tiles. With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;). I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if you're asking about that, or about communicating the information to users. 2. Mock objects. Currently, Struts contains mocks for the servlet, but these classes would be useful for subprojects as well. I suggest we adopt StrutsTestCase, or another test package, as a subproject or dependency I still haven't taken the time to look at StrutsTestCase. If we used that for our own testing, I assume, from what you say, that we could then ditch the mock objects we have today? (What does StrutsTestCase use for its own unit tests?) 3. Cactus. I admit, I never got this working, and now with taglibs and tiles unit
RE: [struts-faces] JSF integration into Struts
already shown, for example, that you can use Tiles and Commons Validator directly with JSF (without using the Struts controller architecture) -- and these are capabilities I already know how to integrate into Shale. Servlet Filters Nice to hear! Is a thing, that will be *public* next week? Then I will play a bit with Shale. It's also quite pleasant to be done with form beans (JSF components already do the stuff we used to need them for); to have the logic to set up a page and process it's input next to each other instead of in two actions that have to be chained; to not need configuration beans at all; to be able to manage multi-request dialogs more gracefully (stay tuned for a Shale example next week); and to be able to use JSF yes, we are ;-) sounds nice! components from multiple libraries; but I digress ... no, you don't ... it is still interessting but perhaps a bit OT ... ;-) Craig Matthias - 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: download link broken or something
the struts.jar that is here: http://svn.apache.org/builds/struts/nightly/ contains package org.apache.struts.chain.commands -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Sent: Friday, December 24, 2004 4:47 PM To: dev@struts.apache.org Subject: download link broken or something from main menu in struts clicking download binaries give a cgi error. Is there another link for 1.3 nigly builds? .V -- RiA-SoA w/JDNC http://www.SandraSF.com forums - help develop a coomunity My blog http://www.sandrasf.com/adminBlog - 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: Taglibs and Tiles Extraction Issues
I have extracted a standalone version of Tiles from Struts 1.1. I've implemented a TilesServlet for using Tiles outside of Struts and a JSF view handler that forwards to a tile instead of a JSP page. I also have some cool examples. that sounds nice! Using Tiles *standalone* is fine! Btw. have you looked at MyFaces' ViewHandler for JSF? I was on the verge of starting an open source project for standalone Tiles that would focus on integration with other presentation technologies besides Struts, such as JSF, Velocity, Tapestry, etc. I want a Tiles version that I can use with JSP only, or with the framework of my choice. And I want Tiles to be integrated as smoothly as possible with my framework. I don't want to have to drag Struts around to do that. I guess it is worth to have *core* tiles + *adapters* for Velocity, Tapestry, JSF, Struts, yet another framework So, I'm not sure what to do with my code. Do my goals for a standalone Tiles align with the goals for the Tiles subproject within Struts? As I said (my personal thoughts): a *core* Tiles version (or call it standalone) is fine. So why not having adapters for other frameworks. In MyFaces we include struts.jar for be able to build our ViewHandler. But this JAR contains *more* than we realy want :-) so I am +1 having tiles *core* as standalone... Regards, Matthias david Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit : On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown [EMAIL PROTECTED] wrote: I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on. 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy this method over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that subprojects will be bundled with Struts releases ala Linux distributions, but how do we communicate intra-subproject dependencies? The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the code within Tiles. With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;). I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if you're asking about that, or about communicating the information to users. 2. Mock objects. Currently, Struts contains mocks for the servlet, but these classes would be useful for subprojects as well. I suggest we adopt StrutsTestCase, or another test package, as a subproject or dependency I still haven't taken the time to look at StrutsTestCase. If we used that for our own testing, I assume, from what you say, that we could then ditch the mock objects we have today? (What does StrutsTestCase use for its own unit tests?) 3. Cactus. I admit, I never got this working, and now with taglibs and tiles unit tests requiring Cactus, I'm not sure how to migrate that build process over, especially as we await the Ant reorganization Martin is working on. I'm leaning to committing all my changes once I got all the code compiling and let someone more knowledgable setup cactus for these two subprojects. It looks like EL solved this by copying the build files. Obviously, this is, um, less than optimal, but until the new build is ready, perhaps we should do the same thing. On the other hand, I don't think we want to put a lot of effort to making this all work when the build system is changing (hopefully next week). -- Martin Cooper Thanks for the help, Don - 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]
Broken link in struts wiki
Hi, on your wiki (http://wiki.apache.org/struts/StrutsRelease126) there is a broken link: 2. [http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleasesHow Signing Releases] -- go here instead (this wiki is now exclusively dedicated to Chinese spam) Could you please tell me the *new* location of that link? Thanks, Matthias Best regards Mit freundlichen Grüßen -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matzew AT apache DOT org URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale vs. Struts-Chain
Hi all, I read the docs on subversion about Shale. Well, a very interessting point. However, I asked myself how it is related to Struts/Commons - Chain. (The Proposal aka Jericho) Has Struts Shale no relationship to (Struts/Commons)-Chain? Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 And Shale, that will be on top of Servlet2.4, will use Filter for CoR, isn't it? Last but not least, the IoC (or dependency injection) from Spring or Hivemind will be *included* into Struts / Shale? Thanks for helping to clear my picture ;-) Greetings, Matthias -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release planning (was Re: Shale vs. Struts-Chain)
Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? read in commons-dev that 1.1.4 is now alpha and available for Testing -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[struts-chain] wiki page?
Hi list, is there a wiki page on Struts-Chain? or only the files inside of contrib/ ? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFC: BLOBAction and Struts Bloat
Craig, In the near future, you'll also see the initial release candidate of the Struts-Faces integration library (packaged separately from the rest of Struts) that allows JavaServer Faces to be used with Struts 1.1 or 1.2 based applications, including the use of the Tiles Framework and the Validator Framework. will the Struts-Faces integration library be a subproject of Apache Struts? Like http://struts.apache.org/struts-faces for instance? Or what are your plans on it? Note that I do *not* see any of the developers interested in continuing the development of the Struts HTML tag libraries, as other view tier choices (like JSF) are becoming available. Btw. like Michael, I am interessted in your proposals on Struts 2.0 too :) Matthias Craig PS: With regards to migrating to SVN (commented on in one of the replies), doing both 1.3 and 2.0 together on SVN will be vastly more productive than using CVS for 1.3 and SVN for 2.0. - 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: [ANN] Bridgetown IoC Framework
Peter, nice! seams interessting. btw. have you looked at: http://jakarta.apache.org/hivemind/ Regards, Matthias -Original Message- From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 8:12 AM To: Struts Developers List Subject: [ANN] Bridgetown IoC Framework Hi I have been quietly working on my own Inversion of Control lightweight framework over the last couple of months. My itch was scratched when I suddenly realised that ``Commons BeanUtils'' and ``Common Digester'' could be simply combined together into a bean assembly factory. An assembly factory could manage service beans in a lightweight container. Services could then be retrieved by name, and one doesn't have to worry about connecting different services together. Experiments showed that this idea was pretty cool and have implemented property and method dependency injection (aka ``BeanUtils'' and ``MethodUtils''). [Constructor injection is on the todo list. ] I am at the point where the current codebase is stable enough for development, but if I want the container to be more useful, then I need to open- source the project. It would allow others to write Dynamic proxy service beans, integrate with Struts 1.2/2+, or extend with AOP library, or whatever persistence layer EJB 3.0 decides to become. It cannot be down by just one man writing software. As an independent consultant I simply have not got the time to build everything. Moreover, I intend to follow the Struts style ``open integration'' philosophy that should allow Bridgetown IoC container to be added any other framework. (I intend add support to the Expresso Framework in the near term, since I am a core committer there) So my simple IoC Test Container became ``Bridgetown IoC''. I uploaded the source code to ``Sourceforge'' and slapped on it an Apache License 2.0 badge. The software is ALPHA quality but it compiles and run with Eclipse SDK 3, and there are junit test and a couple of examples. `` http://bridgetown.sf.net '' is the hook. I'd like publicly thank the man, Craig McClanahan, for his two inventions `BeanUtils' and `Digester'. Without those two components it just wouldn't have happened. Enjoy baby bop# -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resumehttp://jroller.com/page/peter_pilgrim || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - 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]
Java Analysis Tool
Hi, I just found an interessting homepage listed on apache.org, however it provides the following links: Unused Code report (via http://pmd.sf.net): http://cvs.apache.org/~tcopeland/pmdweb/ (it contains a link to struts) and Unused imports (green for Struts!! ;-)): http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Regards, Matthias -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
Ah, now I see... thanks, over I changed all xmls for the TLDs to *old* URI, I created a bugzilla-ticket for it; so you will be able to put old AND new URI to JAR$/META-INF/ URL for Bug #31021 http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 Regards, Matthias -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 6:28 AM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp On Wed, 1 Sep 2004 18:45:22 -0400, Deadman, Hal [EMAIL PROTECTED] wrote: Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: That was exactly my point. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Otherwise, a Struts 1.1 application that relies on the implicit TLD registration done by the container (i.e. *not* listing the TLDs explicitly in web.xml) will go down in flames when run against Struts 1.2.x, unless you go fix the taglib directives in every single page. Basically, it's the same reason that Struts 1.2.x accepts and processes 1.0 and 1.1 versions of struts-config.xml files ... so that older apps can run with minimal changes when you upgrade Struts. It turns out that this doesn't matter for the particular commit message I replied on (which only changed the URI for the struts-faces TLD), but it's an important backwards compatibility principle in general. 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]
RE: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
Martin, ok, sorry... for bothering you all. I misunderstand the mail(s) before. Regards, Matthias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:09 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el)) DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cg i?id=31021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) --- Additional Comments From [EMAIL PROTECTED] 2004-09-02 18:08 --- We really don't want to duplicate the XML files for this. We should be able to generate the old from the new using either an XSLT stylesheet with the Ant style task or with the Ant replace task. - 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]
URI in Struts-1.2.3 (was RE: Struts 1.2.2 Dead in the Water?)
I saw in CVS,
that URI for Struts-Faces points
also to Jakarta:
urihttp://jakarta.apache.org/struts/tags-faces/uri
@struts-el:
only tiles-el points to jakarta
(in Struts 1.2.3)
urihttp://struts.apache.org/tags-bean-el/uri
urihttp://struts.apache.org/tags-html-el/uri
urihttp://struts.apache.org/tags-logic-el/uri
urihttp://jakarta.apache.org/struts/tags-tiles-el/uri
Regards,
Matthias
-Original Message-
From: Kunal Parikh [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 9:15 AM
To: Struts Developers List
Subject: Re: Struts 1.2.2 Dead in the Water?
The taglib URI for struts-el is
http://jakarta.apache.org/struts/tags-tiles-el
Should this URI really be http://struts.apache.org/tags-tiles-el
Note: the non-el version seems to be more in line with the
other taglib URIs http://struts.apache.org/tags-tiles
HTH,
Kunal
Niall Pemberton wrote:
Martin,
I tested out the Struts 1.2.3 binary distribution you
uploaded. The JDK
issue is resolved but the wrong version of the validator jar
is still
being shipped. Now though its more consistent because the lib
distribution also has the wrong jar as well :-)
The disappointing thing from my point of view was that I put a
checklist for testing various JDK/Tomcat flavours in the
Struts 1.2.2
release plan - but it was removed. If they had been left in the plan
then the JDK issues would have been caught.
I've set up a new plan for Struts 1.2.3 on the wiki:
http://wiki.apache.org/struts/StrutsRelease123
Niall
- Original Message -
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 6:28 AM
Subject: Re: Struts 1.2.2 Dead in the Water?
On Wed, 1 Sep 2004 05:16:44 +0100, Niall Pemberton
[EMAIL PROTECTED] wrote:
I've just got round to testing Struts 1.2.2 and found the following
major
problems:
* The binary distribution contains the wrong version of commons
validator
jar (the lib distribution seems to have the right one).
This leads me to believe that the binary and lib distros come from
different builds, which seems pretty odd. The 'release'
target builds
everything at once.
* Struts 1.2.2 is incompatible with JDK 1.3 because it uses
Boolean.valueOf(boolean) introduced in JDK 1.4
This was my fault for doing what FindBugs told me. ;-{ Pity nobody
caught it before 1.2.2 went out.
Also this distribution has been built/packaged differently to
previous releases and IMO we should be doing things consistently:
* The binary distribution zip file explodes to
jakarta-struts-1.2.2/dist/
directory rather than just jakarta-struts-1.2.2/
* The source distribution zip file explodes to jakarta-struts
directory rather than jakarta-struts-1.2.2-src
* The source distribution contains all the CVS directories
and files
This is very strange. I just ran 'ant release' on my local
system, and
it worked just fine, creating all of the uploads correctly.
I see none
of the above issues. Perhaps James built the distros some
other way?
Not sure.
James has just fixed the JDK 1.3 incompatibilities in CVS
but I would
say we
need to downgrade the 1.2.2 version from a GA quality
release and cut
a
new
one.
Yes indeed. I've updated the build version, rolled a new release
distribution, and am in the process of uploading it to
cvs.apache.org.
I have not tested it yet, and have not signed it, but if
people have
the chance to try it out, that would be very helpful.
--
Martin Cooper
Niall
-
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: URI in Struts-1.2.3 (was RE: Struts 1.2.2 Dead in the Water?)
but there aren't
copies either on struts.apache.org or
jakarata.apache.org/struts. Anyone know if this is an issue?
jup, but in struts.jar$/META-INF/tlds
there are the *.tlds
like for JSF:
--
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
Matze
Niall
- Original Message -
From: Matthias Wessendorf [EMAIL PROTECTED]
To: 'Struts Developers List' [EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 8:57 AM
Subject: URI in Struts-1.2.3 (was RE: Struts 1.2.2 Dead in the Water?)
I saw in CVS,
that URI for Struts-Faces points
also to Jakarta:
urihttp://jakarta.apache.org/struts/tags-faces/uri
@struts-el:
only tiles-el points to jakarta
(in Struts 1.2.3) urihttp://struts.apache.org/tags-bean-el/uri
urihttp://struts.apache.org/tags-html-el/uri
urihttp://struts.apache.org/tags-logic-el/uri
urihttp://jakarta.apache.org/struts/tags-tiles-el/uri
Regards,
Matthias
-Original Message-
From: Kunal Parikh [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 9:15 AM
To: Struts Developers List
Subject: Re: Struts 1.2.2 Dead in the Water?
The taglib URI for struts-el is
http://jakarta.apache.org/struts/tags-tiles-el
Should this URI really be http://struts.apache.org/tags-tiles-el
Note: the non-el version seems to be more in line with the other
taglib URIs http://struts.apache.org/tags-tiles
HTH,
Kunal
Niall Pemberton wrote:
Martin,
I tested out the Struts 1.2.3 binary distribution you
uploaded. The JDK
issue is resolved but the wrong version of the validator jar
is still
being shipped. Now though its more consistent because the lib
distribution also has the wrong jar as well :-)
The disappointing thing from my point of view was that I put a
checklist for testing various JDK/Tomcat flavours in the
Struts 1.2.2
release plan - but it was removed. If they had been left in the
plan then the JDK issues would have been caught.
I've set up a new plan for Struts 1.2.3 on the wiki:
http://wiki.apache.org/struts/StrutsRelease123
Niall
- Original Message -
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 6:28 AM
Subject: Re: Struts 1.2.2 Dead in the Water?
On Wed, 1 Sep 2004 05:16:44 +0100, Niall Pemberton
[EMAIL PROTECTED] wrote:
I've just got round to testing Struts 1.2.2 and found the
following
major
problems:
* The binary distribution contains the wrong version of commons
validator
jar (the lib distribution seems to have the right one).
This leads me to believe that the binary and lib
distros come from
different builds, which seems pretty odd. The 'release'
target builds
everything at once.
* Struts 1.2.2 is incompatible with JDK 1.3 because it uses
Boolean.valueOf(boolean) introduced in JDK 1.4
This was my fault for doing what FindBugs told me. ;-{
Pity nobody
caught it before 1.2.2 went out.
Also this distribution has been built/packaged differently to
previous releases and IMO we should be doing things
consistently:
* The binary distribution zip file explodes to
jakarta-struts-1.2.2/dist/
directory rather than just jakarta-struts-1.2.2/
* The source distribution zip file explodes to jakarta-struts
directory rather than jakarta-struts-1.2.2-src
* The source distribution contains all the CVS directories
and files
This is very strange. I just ran 'ant release' on my local
system, and
it worked just fine, creating all of the uploads correctly.
I see none
of the above issues. Perhaps James built the distros some
other way?
Not sure.
James has just fixed the JDK 1.3 incompatibilities in CVS
but I would
say we
need to downgrade the 1.2.2 version from a GA quality
release and cut
a
new
one.
Yes indeed. I've updated the build version, rolled a
new release
distribution, and am in the process of uploading it to
cvs.apache.org.
I have not tested it yet, and have not signed it, but if
people have
the chance to try it out, that would be very helpful.
--
Martin Cooper
Niall
---
--
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: Release notes error?
...an old discussion... http://issues.apache.org/bugzilla/show_bug.cgi?id=29679 Regards, Matthias -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 7:09 PM To: Struts Developers List Subject: Re: Release notes error? The class has not been deprecated because it is part of the public API of the ActionForm class, which is obviously routinely subclassed for Struts apps. Joe At 12:23 PM -0400 9/1/04, Kris Schneider wrote: This thread on TSS: http://www.theserverside.com/news/thread.tss?thread_id=28428 points out an error in the release notes (or perhaps the JavaDoc) concerning the deprecation of ActionErrors. From the What's new? section: Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. Before submitting a bug report, I just want to verify where the bug is. Should the release notes use ActionError/ActionMessage instead of ActionErrors/ActionMessages? Should the JavaDoc for ActionErrors be changed so that the class really is deprecated (currently, only its methods and fields are deprecated)? Should the paragraph quoted above be changed to: Although not deprecated, in many cases you should replace ActionErrors with the preferred ActionMessages to ensure correct operation. Depending on what needs to be changed, I may have been premature in my response to the thread ;-). Of course, it would have been more fun to fire something back at graham o'regan, but I've always been impressed with the professional attitude of the Struts developers in the face of public idiocy. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
Perhaps I am missing something, but the only change was jakarta.apache.org/struts -- struts.apache.org in .TLD-file and in JSPs (for 'uri'-attribute) Regards, Matthias -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 7:17 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp On 1 Sep 2004 11:34:00 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: niallp 2004/09/01 04:34:00 Modified:contrib/struts-faces/web/example logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/example2 footer.jsp header.jsp layout.jsp layout1.jsp loggedoff.jsp loggedon.jsp logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp Log: Change jsp taglib URIs to struts.apache.org - thanks to Matthias Wessendorf for spotting this Doesn't this mean that the apps would not run in a Struts 1.1 environment? If so, that's not acceptable, and I'm -1 on this change. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) 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]
RE: Release notes error?
Kris, ah I saw the section :) Yes, I guess it must be ActionMessage instead of ACtionError, :) -Original Message- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 7:37 PM To: Struts Developers List Subject: Re: Release notes error? No doubt. Then it sounds like the error is in the release notes, yes? There's an additional post in the TSS thread that the JavaDoc class comment for ActionErrors includes: Each individual error is described by an ActionError object... Which, strictly speaking, is inaccurate since you can also add ActionMessage objects. Quoting Matthias Wessendorf [EMAIL PROTECTED]: ...an old discussion... http://issues.apache.org/bugzilla/show_bug.cgi?id=29679 Regards, Matthias -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 7:09 PM To: Struts Developers List Subject: Re: Release notes error? The class has not been deprecated because it is part of the public API of the ActionForm class, which is obviously routinely subclassed for Struts apps. Joe At 12:23 PM -0400 9/1/04, Kris Schneider wrote: This thread on TSS: http://www.theserverside.com/news/thread.tss?thread_id=28428 points out an error in the release notes (or perhaps the JavaDoc) concerning the deprecation of ActionErrors. From the What's new? section: Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. Before submitting a bug report, I just want to verify where the bug is. Should the release notes use ActionError/ActionMessage instead of ActionErrors/ActionMessages? Should the JavaDoc for ActionErrors be changed so that the class really is deprecated (currently, only its methods and fields are deprecated)? Should the paragraph quoted above be changed to: Although not deprecated, in many cases you should replace ActionErrors with the preferred ActionMessages to ensure correct operation. Depending on what needs to be changed, I may have been premature in my response to the thread ;-). Of course, it would have been more fun to fire something back at graham o'regan, but I've always been impressed with the professional attitude of the Struts developers in the face of public idiocy. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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 -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - 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: JSF vs Struts
Jacob, perhaps you remember, we mailed on JSF-EL... however, some minutes ago, i mailed your mail to myfaces-develop-list. since it was deep in my incoming-mail-folder... :-) have you checked out MyFaces-CVS-Head yet? so perhaps you can do some performance-issue there too. btw. does yours support portlet? myfaces doesn't - for now - btw. since some days there is tiles-support and so on, with a special, optional TilesViewHandlerImpl.clazz see more on http://sourceforge.net/projects/myfaces regards, Matthias -Original Message- From: James Holmes [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 5:28 PM To: 'Struts Developers List' Subject: RE: JSF vs Struts The MyFaces open source project is currently becoming an official Apache project through the Apache Incubator. MyFaces has some custom components along with its full implementation of the JSF spec. Perhaps you could contribute to that project?? -James http://www.jamesholmes.com/JavaServerFaces/ -Original Message- From: Hookom, Jacob [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 10:27 AM To: 'Struts Developers List' Subject: RE: JSF vs Struts Would there be any interest in starting an Apache JSF implementation with a component repository for the open source community? I have about 80% of an implementation written... Regards, Jacob -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 12:13 PM To: Struts Users Mailing List Subject: Re: JSF vs Struts On Mon, 19 Jul 2004 10:25:13 -0400, Rick Reumann [EMAIL PROTECTED] wrote: We're thinking about using Flash forms for some things. Will they plugin nicely to JSF? Hooking up the output side of that should be a piece of cake ... write some components that render the necessary markup to embed the Flash stuff in the generated page. I'm not familiar with the input side of using Flash for this, but in principle it should still just be a matter of having your component (or renderer) decode() method parse the appropriate request parameters and store the values, just as the standard HTML components do. 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] - 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]
message-resources
hi, whats against to set in message-resources the null default-value to false? so you got messages like (???net.wessendorf.fooBar???) this is in JSF default, too any comments? Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: HELP FROM THE ADMINISTRATOR re: Brian Husted not available
+1
since this mail comes up since days... or weeks?
regards,
-Original Message-
From: Emmanouil Batsis [mailto:[EMAIL PROTECTED]
Sent: Friday, July 09, 2004 10:31 AM
To: Struts Users Mailing List
Subject: Re: HELP FROM THE ADMINISTRATOR re: Brian Husted not available
+1
Michael McGrady wrote:
It seems that we have been getting the messages that Brian Husted is
not
available forever. Can the administrator please solve this?
Everytime
I send an email to the list I get this back, and others have made the
same complaint:
Subject: Undeliverable: Re: html:image vs html:submit
To: [EMAIL PROTECTED]
Your message
To: Struts Users Mailing List
[EMAIL PROTECTED]@[EMAIL PROTECTED]
Subject: Re: html:image vs html:submit
Sent:Thu, 8 Jul 2004 16:53:00 -0400
did not reach the following recipient(s):
Brian Husted on Thu, 8 Jul 2004 20:53:00 -0400
User Brian Husted/AMS/AMSINC (Brian Husted/AMS/[EMAIL PROTECTED]) not
listed in public Name Address Book
Original-Envelope-ID: c=us;a=
;p=AMS;l={52F5B406-3C-040708205422Z-61510
Reporting-MTA: dns; CARNEY.ams.com
Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.0
X-Display-Name: Brian Husted
MIME-Version: 1.0
Content-Type: text/plain;
charset=us-ascii
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Subject: Re: html:image vs html:submit
Date: Thu, 8 Jul 2004 16:53:00 -0400
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: html:image vs html:submit
Thread-Index: AcRlLcMZx+5rrXGrQSKxkZglX8UWww==
From: [EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]
ams.com
To: Struts Users Mailing List
[EMAIL PROTECTED]@[EMAIL PROTECTED]
IMCEANOTES-Struts+20Users+20Mailing+20List+20+3Cuser+40struts+2Eapache+
[EMAIL PROTECTED]
This tells you where the problem is. If you look at the code there
you should be able to tell what is going wrong. At 01:33 PM 7/8/2004,
you wrote:
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(Proper
tyUtils.java:837)
-
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: FW: HELP FROM THE ADMINISTRATOR re: Brian Husted not available
thanks
seams to work now
regards,
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Friday, July 09, 2004 4:48 PM
To: Struts Developers List
Subject: Re: FW: HELP FROM THE ADMINISTRATOR re: Brian Husted
not available
The last time I tried to do this, the ezmlm tools didn't want
to work for
me. This time, I've removed [EMAIL PROTECTED], which I
assume is the
subscribed address that's causing the problem.
--
Martin Cooper
On Fri, 9 Jul 2004, Matthias Wessendorf wrote:
+1
since this mail comes up since days... or weeks?
regards,
-Original Message-
From: Emmanouil Batsis [mailto:[EMAIL PROTECTED]
Sent: Friday, July 09, 2004 10:31 AM
To: Struts Users Mailing List
Subject: Re: HELP FROM THE ADMINISTRATOR re: Brian Husted not
available
+1
Michael McGrady wrote:
It seems that we have been getting the messages that Brian
Husted is
not available forever. Can the administrator please solve this?
Everytime
I send an email to the list I get this back, and others
have made the
same complaint:
Subject: Undeliverable: Re: html:image vs html:submit
To: [EMAIL PROTECTED]
Your message
To: Struts Users Mailing List
[EMAIL PROTECTED]@[EMAIL PROTECTED]
Subject: Re: html:image vs html:submit
Sent:Thu, 8 Jul 2004 16:53:00 -0400
did not reach the following recipient(s):
Brian Husted on Thu, 8 Jul 2004 20:53:00 -0400
User Brian Husted/AMS/AMSINC (Brian
Husted/AMS/[EMAIL PROTECTED]) not
listed in public Name Address Book
Original-Envelope-ID: c=us;a=
;p=AMS;l={52F5B406-3C-040708205422Z-61510
Reporting-MTA: dns; CARNEY.ams.com
Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.0
X-Display-Name: Brian Husted
MIME-Version: 1.0
Content-Type: text/plain;
charset=us-ascii
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Subject: Re: html:image vs html:submit
Date: Thu, 8 Jul 2004 16:53:00 -0400
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re: html:image vs html:submit
Thread-Index: AcRlLcMZx+5rrXGrQSKxkZglX8UWww==
From: [EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]
i-
ams.com
To: Struts Users Mailing List
[EMAIL PROTECTED]@[EMAIL PROTECTED]
IMCEANOTES-Struts+20Users+20Mailing+20List+20+3Cuser+40struts+2Eapach
e+
[EMAIL PROTECTED]
This tells you where the problem is. If you look at the
code there
you should be able to tell what is going wrong. At 01:33
PM 7/8/2004,
you wrote:
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(Prop
er
tyUtils.java:837)
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom validators: ActionMessages vs ActionErrors
see http://struts.apache.org/userGuide/release-notes.html -- Whats new Although not removed, in many cases you should replace the deprecated ActionErrors with the preferred ActionMessages to ensure correct operation. reason is ActionErroR is deprecated... ActionErrorS can't -- validate() returns that guy. so with ActionMessages in validate() there is no backward-compatibility regards, -Original Message- From: Ng Chong Hin NCS [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 7:22 PM To: '[EMAIL PROTECTED]' Subject: Custom validators: ActionMessages vs ActionErrors Had installed Struts 1.2.1 on the local machine and everything runs smoothly ... except for my Struts 1.1 custom validators. Previously, the method signature in the validator was: public static boolean validateFromToDate(Object bean, ValidatorAction va, Field field, ActionErrors oErrors, HttpServletRequest request) Inside the method, when validation fails, a call to oErrors would throw a NullPointerException. oErrors.add (field.getKey (), Resources.getActionError (request, va, field)); Changing the method signature would resolve the NPE: public static boolean validateFromToDate(Object bean, ValidatorAction va, Field field, ActionMessages oErrors, HttpServletRequest request) Has anyone encountered this issue? Besides this, all seems to be well (so far)! Cheers, Chong Hin - 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: UNSUBSCRIBE!
-Original Message- From: Swaminathan_g [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 8:55 PM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE! Dear all, I have tried innumerable number of times to unsubscribe from this mailing list. I am unable to. I successfully managed to unsubscribe two other mailing lists of Struts. But not this one. Every time I send an email to [EMAIL PROTECTED] EI dont get a response back. Can someone please help me unsubsribe from this mailing list? Sorry about this - and thanks for your help, -Swami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: UNSUBSCRIBE!
Martin, thanks for you information, but i didn't know it before... sorry for bothering you. Matthias -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 11:13 PM To: Struts Developers List Subject: Re: FW: UNSUBSCRIBE! Please send messages like this to the list owners rather than the dev list. In this case, it would have been [EMAIL PROTECTED] (Of course, the user should have done that himself...) Thanks. -- Martin Cooper On Fri, 9 Jul 2004, Matthias Wessendorf wrote: -Original Message- From: Swaminathan_g [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 8:55 PM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE! Dear all, I have tried innumerable number of times to unsubscribe from this mailing list. I am unable to. I successfully managed to unsubscribe two other mailing lists of Struts. But not this one. Every time I send an email to [EMAIL PROTECTED] EI dont get a response back. Can someone please help me unsubsribe from this mailing list? Sorry about this - and thanks for your help, -Swami - 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]
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,
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: Struts-faces
In principle, this makes perfect sense. It'll be easy if you've split the MyFaces jars into api and impl classes (like the RI does), because then it's just a matter of setting up your own build.properties file and defining jsf-api.jar and jsf-impl.jar appropriately. no, not now. but i mean also the use of myfaces in the examples. so it would be much easier for users, since JSF (myfaces) is delivered directly for running the WAR-files. matthias I'll look into seeing if that actually works, once I've caught up and made sure that struts-faces works with the current version of the RI (the code I'm most familiar with). But that has to wait until I do penance for being offline for a couple of months, by taking a whack at our failing cookie-related Cactus tests :-). cheers, matthias Craig On Mon, 05 Jul 2004 18:56:41 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Ted Husted wrote: I imagine Craig has Struts-Faces compiling against 2.4 to make sure it stays in synch with Tomcat 5. It is indeed, but that's actually a mistake. It needs to compile against the 2.3 version, since that's what JSF specifies as a minimum platform. I'll fix that in tonight's run. But, the question is whether we want to mandate that Struts-Faces can only compile against 2.3 (and not 2.4)? Or vice-versa. Or is there a way to write the class so it compiles under either? I'll take a look at the changes once I catch up a little bit more, and might be able to come up with something clever that makes this possible (still recovering from JavaOne and ~11k backlogged mail messages :-). I know this is a pain. We went through the same problem with DataSources between 2.2 and 2.3. I'm not sure what the issue here is, but for DataSources, the interface changed and we had to stub the new members so that they threw exceptions if called. Of course, the problem with that approach is it may obviate new functionality or rely on deprecated methods. -Ted. Craig On Mon, 05 Jul 2004 14:14:02 +0200, Matthias Wessendorf wrote: James, i also guess it is the result of the commitment. i submitted (first) a wrapper, that builds against 2.4 reason is, the build-porperties had *default* to 2.4 okay ted asks for a 2.3-wrapper, so i created that candidate. i think the wrapper should compile against 2.3 since jsf is able to run in j2ee1.3-containers So i am wondering, why struts-faces uses 2.4 for compiling. btw. the 2.3 wrapper runs on servlet2.4-containers (like tomcat5.0) Matthias I think it is happening because of the changes I committed for your fix for MyFaces. If you look at when the builds stopped, it's right after I made the commits on 6/29. It must be an issue of what version of servlet.jar that the HttpServletRequestWrapper class is being compiled against. Is it not possible to make that class compilable against both 2.3 and 2.4? -James -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] wessendorf.de] Sent: Monday, July 05, 2004 6:29 AM To: [EMAIL PROTECTED] Subject: Struts-faces see http://cvs.apache.org/builds/jakarta-struts/nightly/struts- faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - - --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Struts-faces
But I'm -1 on including MyFaces in any Struts distribution until it has passed the TCK tests to certify that it is a compatible implementation of JavaServer Faces. Assistance in making that happen is one of the benefits you'll get by becoming an Apache project (once MyFaces passes through the incubation process), because Apache already has access to all the relevant TCK tests without having to apply for the scholarship that is available for non-profit orgs. nice to hear, out father (Manfred Geiler) has allready mailed to sun on the TCK-issue. but no response now, i guess... :-( so, i guess we may wait till we pass incubation... ;-) But, until it does, it would be a disservice to Struts users to package something that represents itself as being JSF when it hasn't been proven to be so. Regarding the split of JARs, I would recommend you do that (javax.faces.* versus everything else) if you have not done so yet. The primary benefit is that users of MyFaces will only need the API jar in their compile time classpath, and will therefore not be tempted to program directly to the implementation classes and therefore lock themselves in to MyFaces (instead of being portable to anyone's JSF implementation). jupp, think so too however in a j2ee-1.5 (or do you call it 5.0 too? :-)) the container will ship the Impl-jars Matthias You'll need to include both the API and IMPL jars in a webapp, of course, but that's already taken care of by the build scripts for the struts-faces examples (assuming you configure the properties correctly). matthias 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]
Struts-faces
see http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts-faces
James, i also guess it is the result of the commitment. i submitted (first) a wrapper, that builds against 2.4 reason is, the build-porperties had *default* to 2.4 okay ted asks for a 2.3-wrapper, so i created that candidate. i think the wrapper should compile agains 2.3 since jsf is able to run in j2ee1.3-containers So i am wondering, why struts-faces uses 2.4 for compiling. btw. the 2.3wrapper runs on servlet2.4-containers (like tomcat5.0) Matthias I think it is happening because of the changes I committed for your fix for MyFaces. If you look at when the builds stopped, it's right after I made the commits on 6/29. It must be an issue of what version of servlet.jar that the HttpServletRequestWrapper class is being compiled against. Is it not possible to make that class compilable against both 2.3 and 2.4? -James -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 6:29 AM To: [EMAIL PROTECTED] Subject: Struts-faces see http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net - 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]
