DO NOT REPLY [Bug 36200] New: - [shale] Clay HTML templates doesn't work with myFaces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36200

   Summary: [shale] Clay HTML templates doesn't work with myFaces
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


If suffix mapping is used, myfaces translates the suffix of all incoming
requests *before* the ViewHandler is called. As result, the clay ViewHandler
is unable to recognize the URL.

The RI does this translation in the default view handler.

The first question is whether the myFaces behavior is acceptable according
to the standard.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Shale Regex Validation Tag

[David Geary]

Le 05-08-12 à 13:40, Craig McClanahan a écrit :


On 8/12/05, Romero, Ron <[EMAIL PROTECTED]> wrote:


[snip]


This would also mean you don't need a new tag ... the existing Shale
tags for integrating validators would work.



Ah, but I want a new tag! :-)  Seriously, a new tag would make it
easier to use --- it's simpler to code and to understand.  True, it
would hide the flexibility and power of the commonsValidator tag, but
we don't need or want that additional flexibility, and we'd like to
hide it from everyone else.




And here's where the suggested approach isn't as appealing to me.
Once you open the floodgates of creating a new tag for *this* sort of
a validator, you likely end up where you need a tag for *every* sort
of validator.  To the maximum degree possible, I'd prefer to stick
with just one tag  that can call any of them.  We
only need to ensure that there is a way to set all the needed
configurable properties such a validator would need.

At the same time, having predefined patterns with easy to use names is
exactly the sort of enhancement that *should* be made at the C-V
level, so that everyone can benefit from it, rather than hiding it
inside Shale :-).


Sorry I'm so late to the party. I've been out of town and I'm  
catching up on email.


Anyway, I agree with Craig. I really like the simplicity of a single  
tag and the

difference between this:



and this:



Is nowhere near compelling enough to introduce a new tag. And the  
benefits

of introducing yet another XML configuration file that encapsulates the
validation specifics of individual fields is dubious at best.  
Personally, I like
being able to see exactly what the validation entails without having  
to go
pawing through a config file, but I know not everyone has that  
preference.



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]

Re: JSF vs. Struts

[Rich Feit]

Hmm... I'm just about to post a reply to that entry.  Basically, I feel 
that although JSF itself can be great view-tier technology, it isn't 
really a full replacement for Struts.  JSF+Shale *is* a replacement for 
Struts, but I think that's a point which is often lost.  An interesting 
thing about Struts Ti is that it would treat JSF as a first-class view 
tier without depending on it for anything else.  That may or may not 
turn out to be important, but it does keep JSF as a peer to other view 
technologies, rather than at the core.


I don't think JSF and Struts are incompatible, as long as JSF is being 
used as a (powerful) view.  Intra-page event handling works fine with 
something like Struts.  When the other more general-framework-type 
functionality is used, there's a conflict.


In general, I agree with the sentiment that there's a lot of hype in 
this arena, and not all of it is easily backed up.  But the Struts 
community has always been a bit hype-adverse, no?


Rich

Matthias Wessendorf wrote:


FYI

http://jroller.com/page/dgeary



 


-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 11, 2005 8:44 AM
To: Struts Developers List
Subject: Re: JSF vs. Struts


I personally think all this exploration is a Very Good 
Thing(tm).  There 
are a vast number of different ideas out there as to how a modern 
application framework should be built.  Mistakes have been 
made over the 
years, lessons have been learned, but we don't all agree on what the 
mistakes were or what the lessons are!  If that sounds bad to 
anyone, it 
isn't.  It's quite the opposite and is the only way healthy 
debate and 
ultimately progress is made.


At some point we're going to have to all weed out the options 
that don't 
quite measure up, and that will happen via simple market forces (the 
market in this case being mostly developer mind share), but I don't 
think that time is now, so the more experimentation, the better.


I for one am not willing to declare one thing better than 
another... I 
regret having done that in the past prematurely, and 
certainly not in a 
manner I'm especially proud of.  So, I'm certainly not going 
to make the 
same mistake twice.


I'm still not sold on JSF, that much has not changed.  I do however 
think there is some decent ideas underpinning it, which is 
also the case 
for many of the other frameworks and approaches out there, so 
declaring 
JSF or anything else for that matter a failure now is 
probably not fair 
either.  I do think Jack's point about JSF being around for a 
while and 
not really setting the world on fire is fair, although that 
doesn't mean 
it has failed, just that it's going a little slower than 
hoped.  My take 
on JSF is simply this: we'll see.  I'm not sold yet, but I'm 
not willing 
to say I never will be.


As for Shale, I'm not sure I understand why Rod or anyone says that 
Struts and JSF are not compatible... if the thinking is that 
the result 
will be quite a bit different from Struts as we know it today, then I 
suppose he might be right.  That to me doesn't make them incompatible 
though.  From what I have seen of JSF, and what I know of 
Struts, I can 
conceive of ways they could be fit together.  I haven't had a 
chance to 
get into Shale yet, but I have no doubt many of those ideas, and many 
more I haven't thought of, are present.  Why they are incompatible I 
just don't get, and I don't care who is making the claim, no 
matter how 
well-respected they are, I need to see some real, concrete examples 
before I'm convinced.


Struts Ti looks pretty interesting... many of the ideas that were 
described here a few days ago were quite good in my mind.  
Should it be 
the future of Struts?  I don't know yet, and I'm not even sure those 
developing it would be willing to say that at this juncture.  It's 
another possible path, another exploration of possibilities, 
and that's 
good.


One thing is for sure: most of us look back on the way we developed 
applications just five years ago and wonder why we ever did 
things that 
way.  I have absolutely no doubt we'll be doing the same thing in 
another five years.  I too would like to see less hype sometimes, but 
promoting ones' ideas is human nature.  If you think you have a 
compelling answer, or even the One True Answer, you tell 
people about it 
and try and convince them.  That's hype.  It may not always 
be helpful, 
but it's perfectly natural :)


Frank

Dakota Jack wrote:
   


I have to agree personally with Rod Johnson "J2EE without EJBs",
Spring framework architect, etc., when he says that Shale 
 


is merely a
   

stopgap and that Struts as we know it is simply 
 


incompatible with JSF.
   


That seems fairly obvious and I find it hard to believe that anyone
familiar with the issues would think any differently.  I personally
would not hire anyone would thought differently, whether 
 


they like JSF
   


or not.

JSF is not new.  JSF h

Re: [ti] first crack at Page Flow support

[Don Brown]

Great!  Thanks for all the hard work Rich; I'm looking forward to getting this 
into Ti ASAP.

Don

Rich Feit wrote:
Quick correction: In both of the sample apps, you need to run 'ant 
build' in WEB-INF/src.  No maven yet.


Rich Feit wrote:


Hi all,

Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbox).  It's basically Beehive Page Flow, minus
Struts 1.x, minus Servlet, plus XWork, plus some refactoring.  And minus
a bunch of functionality that I had to disable in the process.

There are three things here:
1) The patch itself.  There are notes below about this.

2) A sample app ("ti-example").  It's not integrated into the tree
at this point, but building/running should be easy:
   - 'maven war' in {ti root}/example, to get the right jars
for WEB-INF/lib.
   - Copy 
{ti-root}/example/target/struts-ti-example/WEB-INF/lib/*.jar into

ti-example/WEB-INF/lib.
   - Deploy ti-example, and (if you're using Tomcat), hit
http://localhost:8080/ti-example/pageflow .

3) Another sample app -- ported from Beehive -- to demonstrate JSF
integration in Struts Ti.  JSF is optional, but it's treated as a
first-class view tier.  JSF pages handle intra-page events, but raise
Page Flow actions for navigation.  The blurb at
http://beehive.apache.org/releases/v1.0m1/pageflow/jsf.html basically
applies here.  To build/run this, follow the steps for (2), and put
myfaces.jar (http://www.myfaces.org/) into WEB-INF/lib.  Then hit
http://localhost:8080/ti-jsf/ .

Note: I can't attach zip files here, so I've put the files at:
1) http://www.cppdoc.com/ti-temp/struts-ti-pageflow-patch.zip
2) http://www.cppdoc.com/ti-temp/ti-example.zip
3) http://www.cppdoc.com/ti-temp/ti-jsf.zip

If you have trouble connecting, let me know and I'll send them to you.


---
Everything below this line is mainly interesting if you're
working/peeking on the Ti source code.

- First, style.  I've given checkstyle a lot to complain about.  I
can work on fixing this (possibly with some discussion about a few of
the parameters) after this goes in -- I didn't want to wait any longer.
Apologies for the magnitude of angst I've caused.  :)

- All of the Page Flow code uses PageFlowActionContext, which is an
ActionContext that puts everything context-related in one place.  It
doesn't use ControllerContext.  Of course, in the end there will be one
thing, but I didn't want to blow up ControllerContext at this point
before having a discussion about how to rationalize all the contexts
(ActionContext, WebContext, Ti Context).

- I created a Chain for the View (kicked off by Servlet Filters).
This required splitting out some config code from StrutsTiServlet.

- Controller action methods and exception handlers currently return
either Forward (a convenience for adding view-setup objects to the
request) or String (simple result lookup).  We can eliminate one or the
other if we decide that's ok.

- Although most Servlet dependencies have been removed from Page
Flow code, there's still a lot of *path* dependence.  The former should
disappear entirely; the latter is something we'll need to discuss.
There's a Chain step -- PopulatePageFlowContext -- that sets up a bunch
of Servlet-like attributes on the context, and this may go away 
eventually.


- *** There is currently no generation of XWork config files from
Page Flow classes/annotations.  All of the sample app config files
(/WEB-INF/src/_pageflow-config/**) are hand-coded.  Generation is a
well-known quantity, and I definitely expect the config file format to
change (especially after the XWork folks tell me how I've misused their
framework ;) ). ***

- Logging.  There's a Logger wrapper used throughout Page Flow.
This will most likely just go away ASAP.

- Controller classes still currently need to extend
PageFlowController.  This is a holdover from Beehive, but we'll change
it so that they can be POJOs.

- Page Flow doesn't use XWork's ability to create a form bean.  The
Page Flow version of this (ChooseFormBean) is currently totally distinct
from everything that happens in CreateFormChain.  It's a very different
process -- the form bean type is retrieved from config, not through
reflection; the scopes are currently "request" or "page flow" (the
latter get/set from member data in the page flow); etc., etc.  I just
didn't want to mess up what's there, but obviously we'll need to
consolidate.

- Page Flow has integration with Commons Validator (through
annotations), but this is not hooked up yet.  I know there's already
been work done in this area.

- Shared Flow support isn't enabled yet, although it's close.

- Page Flow isn't currently using the ActionMapper for creating
action URIs.

- The JSF sample still has "beehive" in its package names.

 - There are three temporary XMLBeans-generated jars that are
required for building the code.  I don't currently have access to my
people.apache.org 

Re: 1.3.0 Release - Next Steps

[Joe Germuska]

At 2:01 PM -0400 8/15/05, Ted Husted wrote:

On 8/15/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:

 Where are the source files, and how were both the HTML files and the TLDs
 getting generated originally?  If someone explains how it used to work, I
 can probably make it work again.


Under the "monolithic" distribution, everything was in the one
UserGuide directory, but when TagLibs became a subproject, the TLD
XML's went over there.

* http://svn.apache.org/viewcvs.cgi/struts/taglib/trunk/doc/userGuide/

What was happening is that two stylesheets were applied to the one
file. One stylesheet was used to generate the UserGuide HTML pages,
and the other stylesheet generated the TLDs.


Ted has this correct.  In fact, the UserGuide HTML pages are 
generated using the base xdoc transformation, and then the TLDs are 
generated with  (in 
taglib/maven.xml)


Especially with the new non-monolithic distribution, it makes sense 
to generate the TLDs one last time, and then commit those to the SVN 
repository instead of the documentation XML, and then to shift to 
using taglibdoc to generate tag documentation as part of the taglib 
sub-documentation tree.


Easy for me to say -- I'm travelling for work this week so won't have 
much time to put towards helping make it work that way.


Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Ted Husted]

On 8/15/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> Where are the source files, and how were both the HTML files and the TLDs
> getting generated originally?  If someone explains how it used to work, I
> can probably make it work again.

Under the "monolithic" distribution, everything was in the one
UserGuide directory, but when TagLibs became a subproject, the TLD
XML's went over there.

* http://svn.apache.org/viewcvs.cgi/struts/taglib/trunk/doc/userGuide/

What was happening is that two stylesheets were applied to the one
file. One stylesheet was used to generate the UserGuide HTML pages,
and the other stylesheet generated the TLDs.

-T.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Wendy Smoak]

From: "Ted Husted" <[EMAIL PROTECTED]>


How are we doing on mavenizing the web site


I'll get the internal links/anchors done this week.  At least it should be 
good enough for 1.3.0, though I'm not sure how we intend to distribute the 
documentation this time around.  The users don't really need the *entire* 
site with all the reports.


I need help with the TLD generation.  Maybe it will be simple once I get a 
chance to look at it... but at first glance, the 'acquiring' page says that 
the TLDs are generated from struts-*.xml files in doc/userGuide [now 
site/xdocs/userGuide] and I don't see any such files.


Where are the source files, and how were both the HTML files and the TLDs 
getting generated originally?  If someone explains how it used to work, I 
can probably make it work again.


Also, we seem to have lost 'database.xml' somewhere along the way.  The 
current site has this page:  http://struts.apache.org/faqs/database.html but 
I don't have it locally.  I haven't gone looking to see if it was removed on 
purpose, but that seems unlikely.


Thanks,
Wendy 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 30401] - ActionMessage should include option for bundle

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30401





--- Additional Comments From [EMAIL PROTECTED]  2005-08-15 19:15 ---
Thank you Niall for adding it to the validation Framework.

I too would like to see it in the Struts codebase.  It makes properties files
more managable especially when it comes time to assign them to different folks
for translation.

I had to modify struts as well as Struts-Layout in order to take advantage of
the bundle defined in the ActionMessage property.  I must say it's works quite
nicely.

Thank you.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Ted Husted]

On 8/15/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> For deprecations, it's a good news/bad news thing.
> 
> Core deprecations are done.  There is one item that is left because I
> wasn't sure if now is the right time to remove it.  The method is
> DynaActionFormClass.clear().  From what I can find, this was
> deprecated 14 months ago.  It's easy to take out if that's what we
> should do now (no references to it that I can find), otherwise we can
> just update the javadoc to state when it'll be taken out.  Checking my
> copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
> about 1.2.0, and I'm also not sure about timeframes.  If it was
> deprecated by 1.2.0, we remove them now.  What if it was only
> deprecated by 1.2.1?  Anyway, like I said, this is a quick fix.

Thanks so much for doing this, Hubert :)

I'd say that the telling point is whether it was deprecated in a prior
GA release.

The idea being that if someone stays current with each GA release, and
resolves the deprecated items before the next GA release, they should
not need to make any changes simply to use the newest release.

Since 1.2.7 was a GA relesae, anything deprecated in 1.2.7 is fair
game (so long as we have a documented alternative to the
functionality).

> 
> I say "core deprecations" because that's where I usually spend time
> at.  For some reason I didn't look for deprecated items in taglibs/el.
>  I found a few items there yesterday afternoon, and they look like
> deprecated attributes that need to be removed.  They could be as
> simple are deleting code, so if anyone out there feels like it, they
> should go ahead and work on those.  If not, I can take a look at them
> one of these weeknights.

The release testing for EL would be constrainted to its version of the
Exercises application, so that won't be so bad to do again later. We
can also cut a Struts el 1.3.1 release and include it in a future
release of the Struts Classic 1.3.x distribution. Ditto for Tiles.


> 
> Tiles, I haven't even checked yet.  Anybody here willing to work on that?
> 
> Hubert
> 
> 
> On 8/15/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> > How are we doing on mavenizing the web site and removing the deprecations?
> >
> > When these two items are stable, I'll apply the remaining patches and
> > try rolling a distribution.
> >
> > -Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Hubert Rabago]

Oh, btw, ResponseUtils has a filter() method that's been deprecated
for 1.2.x because the functionality was moved to TagUtils.  Now that
TagUtils is in another project, the filter code is back in
ResponseUtils.  It's still marked deprecated, and someone asked why in
the javadoc.  If no one objects, and no one does it before me, I'll be
removing the deprecated tag on this method.

Hubert

On 8/15/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> For deprecations, it's a good news/bad news thing.
> 
> Core deprecations are done.  There is one item that is left because I
> wasn't sure if now is the right time to remove it.  The method is
> DynaActionFormClass.clear().  From what I can find, this was
> deprecated 14 months ago.  It's easy to take out if that's what we
> should do now (no references to it that I can find), otherwise we can
> just update the javadoc to state when it'll be taken out.  Checking my
> copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
> about 1.2.0, and I'm also not sure about timeframes.  If it was
> deprecated by 1.2.0, we remove them now.  What if it was only
> deprecated by 1.2.1?  Anyway, like I said, this is a quick fix.
> 
> I say "core deprecations" because that's where I usually spend time
> at.  For some reason I didn't look for deprecated items in taglibs/el.
>  I found a few items there yesterday afternoon, and they look like
> deprecated attributes that need to be removed.  They could be as
> simple are deleting code, so if anyone out there feels like it, they
> should go ahead and work on those.  If not, I can take a look at them
> one of these weeknights.
> 
> Tiles, I haven't even checked yet.  Anybody here willing to work on that?
> 
> Hubert
> 
> 
> On 8/15/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> > How are we doing on mavenizing the web site and removing the deprecations?
> >
> > When these two items are stable, I'll apply the remaining patches and
> > try rolling a distribution.
> >
> > -Ted.
> >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Hubert Rabago]

For deprecations, it's a good news/bad news thing.

Core deprecations are done.  There is one item that is left because I
wasn't sure if now is the right time to remove it.  The method is
DynaActionFormClass.clear().  From what I can find, this was
deprecated 14 months ago.  It's easy to take out if that's what we
should do now (no references to it that I can find), otherwise we can
just update the javadoc to state when it'll be taken out.  Checking my
copies of old Struts, it was deprecated by 1.2.1, but I'm not sure
about 1.2.0, and I'm also not sure about timeframes.  If it was
deprecated by 1.2.0, we remove them now.  What if it was only
deprecated by 1.2.1?  Anyway, like I said, this is a quick fix.

I say "core deprecations" because that's where I usually spend time
at.  For some reason I didn't look for deprecated items in taglibs/el.
 I found a few items there yesterday afternoon, and they look like
deprecated attributes that need to be removed.  They could be as
simple are deleting code, so if anyone out there feels like it, they
should go ahead and work on those.  If not, I can take a look at them
one of these weeknights.

Tiles, I haven't even checked yet.  Anybody here willing to work on that?

Hubert


On 8/15/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> How are we doing on mavenizing the web site and removing the deprecations?
> 
> When these two items are stable, I'll apply the remaining patches and
> try rolling a distribution.
> 
> -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]

DO NOT REPLY [Bug 35127] - [taglib] All Javascript validation fails when is present

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=35127





--- Additional Comments From [EMAIL PROTECTED]  2005-08-15 15:31 ---
(In reply to comment #8)
> Fixed in changeset [232636]  Thanks for the patch!

Thanks for applying the patch, Don. Just to be complete, it is patchset 232626
and not 232636 :-)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Ted Husted]

How are we doing on mavenizing the web site and removing the deprecations?

When these two items are stable, I'll apply the remaining patches and
try rolling a distribution.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Struts Wiki] Update of "StrutsClassicRelease130" by TedHusted

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by TedHusted:
http://wiki.apache.org/struts/StrutsClassicRelease130

The comment on the change is:
Update status

--
  
  
  || '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=33132 33132] || 
[upload] org.apache.struts.upload.MultipartRequestWrapper...  || File Upload  
|| _ ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=33132 33132] || 
[upload] org.apache.struts.upload.MultipartRequestWrapper...  || File Upload  
|| Patch Available ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35155 35155] || 
PropertyMessageResources.loadLocale(String localeKey) has...  || Utilities  || 
_ ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35155 35155] || 
PropertyMessageResources.loadLocale(String localeKey) has...  || Utilities  || 
Patch Available ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35477 35477] || 
TagUtils.getActionMappingURL() does not consider "/*.do" ...  || Custom Tags  
|| (./) Added to FAQ ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35513 35513] || 
multiform validation  || Validator || Confirm  issue ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35806 35806] || 
[taglib/validator] quotes not properly escaped in dynamic...  || Validator || 
Patch available||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35806 35806] || 
[taglib/validator] quotes not properly escaped in dynamic...  || Validator || 
Patch Available||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35895 35895] || 
Attributes with false in TLD p...  || Custom Tags  
|| _ ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35895 35895] || 
Attributes with false in TLD p...  || Custom Tags  
|| Apply as to Tiles attribute ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35931 35931] || [el] 
Example webapp missing || EL || (./) ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35933 35933] || [apps] 
Source code missing from example apps  || Apps || (./) ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35953 35953] || Remove 
deprecations prior to 1.3.0 release || All || _ ||
@@ -77, +77 @@

  == Other TODO ==
  OTHER TODO
  
+ || '''Summary''' || '''Status''' ||
+ ||Mavenize website || _ ||
-  * Build - Remove remaining Ant build files(unless someone is going to 
volunteer to maintain them)
-  * Website - Add link to nightly builds 
(http://svn.apache.org/builds/jakarta-struts/maven/)
- 
  
  == Preparation Checklist ==
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36124] - [tiles] Attributes in ComponentContext set via Controller not availiabe in JSP

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36124


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Attributes in   |[tiles] Attributes in
   |ComponentContext set via|ComponentContext set via
   |Controller not availiabe in |Controller not availiabe in
   |JSP |JSP




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project struts-core (in module struts) failed

[Stefan Bodewig]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-core has an issue affecting its community integration.
This issue affects 21 projects,
 and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- avalon-http-context :  Avalon SVN
- avalon-http-demo :  Avalon SVN
- avalon-http-examples :  Avalon SVN
- avalon-http-impl :  Avalon SVN
- avalon-http-server :  Avalon SVN
- avalon-http-servlet :  Avalon SVN
- avalon-http-static :  Avalon SVN
- avalon-http-test :  Avalon SVN
- avalon-planet-facilities :  Avalon SVN
- fulcrum-quartz :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-velocity-tools :  Velocity-Tools project
- metro-reflector-blocks-complete :  Avalon SVN
- myfaces :  JavaServer(tm) Faces implementation
- quartz :  Job Scheduler
- struts-core :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-taglib-from-packages :  Model 2 Model-View-Controller framework 
for Servlets and JSP
- struts-tiles :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- strutstestcase :  An extension of the standard JUnit TestCase class that 
provi...


Full details are available at:
http://vmgump.apache.org/gump/public/struts/struts-core/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts.jar] identifier set to project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
xerces.jar.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/struts/struts-core/gump_work/build_struts_struts-core.html
Work Name: build_struts_struts-core (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar
 
-Djakarta-oro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-15082005.jar
 
-Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-15082005.jar
 -Dantlr.jar=/usr/local/gump/packages/antlr-2.7.3/antlr.jar 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15082005.jar
 
-Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-15082005.jar
 -Djdk.version=1.4 
-Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar
 
-Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar
 
-Dcommons-digester-rss.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/src/examples/rss/dist/commons-digester-rss.jar
 
-Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15082005.jar
 
-Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-15082005.jar
 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 dist 
[Working Directory: /usr/local/gump/public/workspace/struts/core]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/core/target/library/classes:/usr/local/gump/public/workspace/struts/core/target/tiles/library/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.j

[EMAIL PROTECTED]: Project struts-core (in module struts) failed

[Stefan Bodewig]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-core has an issue affecting its community integration.
This issue affects 21 projects,
 and has been outstanding for 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- avalon-http-context :  Avalon SVN
- avalon-http-demo :  Avalon SVN
- avalon-http-examples :  Avalon SVN
- avalon-http-impl :  Avalon SVN
- avalon-http-server :  Avalon SVN
- avalon-http-servlet :  Avalon SVN
- avalon-http-static :  Avalon SVN
- avalon-http-test :  Avalon SVN
- avalon-planet-facilities :  Avalon SVN
- fulcrum-quartz :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-velocity-tools :  Velocity-Tools project
- metro-reflector-blocks-complete :  Avalon SVN
- myfaces :  JavaServer(tm) Faces implementation
- quartz :  Job Scheduler
- struts-core :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-taglib-from-packages :  Model 2 Model-View-Controller framework 
for Servlets and JSP
- struts-tiles :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- strutstestcase :  An extension of the standard JUnit TestCase class that 
provi...


Full details are available at:
http://vmgump.apache.org/gump/public/struts/struts-core/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts.jar] identifier set to project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
xerces.jar.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/struts/struts-core/gump_work/build_struts_struts-core.html
Work Name: build_struts_struts-core (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar
 
-Djakarta-oro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-15082005.jar
 
-Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-15082005.jar
 -Dantlr.jar=/usr/local/gump/packages/antlr-2.7.3/antlr.jar 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-15082005.jar
 
-Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-15082005.jar
 -Djdk.version=1.4 
-Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar
 
-Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar
 
-Dcommons-digester-rss.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/src/examples/rss/dist/commons-digester-rss.jar
 
-Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-15082005.jar
 
-Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-15082005.jar
 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 dist 
[Working Directory: /usr/local/gump/public/workspace/struts/core]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/core/target/library/classes:/usr/local/gump/public/workspace/struts/core/target/tiles/library/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.j

Re: [ti] first crack at Page Flow support

[Rich Feit]

Quick correction: In both of the sample apps, you need to run 'ant 
build' in WEB-INF/src.  No maven yet.


Rich Feit wrote:


Hi all,

Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbox).  It's basically Beehive Page Flow, minus
Struts 1.x, minus Servlet, plus XWork, plus some refactoring.  And minus
a bunch of functionality that I had to disable in the process.

There are three things here:
1) The patch itself.  There are notes below about this.

2) A sample app ("ti-example").  It's not integrated into the tree
at this point, but building/running should be easy:
   - 'maven war' in {ti root}/example, to get the right jars
for WEB-INF/lib.
   - Copy 
{ti-root}/example/target/struts-ti-example/WEB-INF/lib/*.jar into

ti-example/WEB-INF/lib.
   - Deploy ti-example, and (if you're using Tomcat), hit
http://localhost:8080/ti-example/pageflow .

3) Another sample app -- ported from Beehive -- to demonstrate JSF
integration in Struts Ti.  JSF is optional, but it's treated as a
first-class view tier.  JSF pages handle intra-page events, but raise
Page Flow actions for navigation.  The blurb at
http://beehive.apache.org/releases/v1.0m1/pageflow/jsf.html basically
applies here.  To build/run this, follow the steps for (2), and put
myfaces.jar (http://www.myfaces.org/) into WEB-INF/lib.  Then hit
http://localhost:8080/ti-jsf/ .

Note: I can't attach zip files here, so I've put the files at:
1) http://www.cppdoc.com/ti-temp/struts-ti-pageflow-patch.zip
2) http://www.cppdoc.com/ti-temp/ti-example.zip
3) http://www.cppdoc.com/ti-temp/ti-jsf.zip

If you have trouble connecting, let me know and I'll send them to you.


---
Everything below this line is mainly interesting if you're
working/peeking on the Ti source code.

- First, style.  I've given checkstyle a lot to complain about.  I
can work on fixing this (possibly with some discussion about a few of
the parameters) after this goes in -- I didn't want to wait any longer.
Apologies for the magnitude of angst I've caused.  :)

- All of the Page Flow code uses PageFlowActionContext, which is an
ActionContext that puts everything context-related in one place.  It
doesn't use ControllerContext.  Of course, in the end there will be one
thing, but I didn't want to blow up ControllerContext at this point
before having a discussion about how to rationalize all the contexts
(ActionContext, WebContext, Ti Context).

- I created a Chain for the View (kicked off by Servlet Filters).
This required splitting out some config code from StrutsTiServlet.

- Controller action methods and exception handlers currently return
either Forward (a convenience for adding view-setup objects to the
request) or String (simple result lookup).  We can eliminate one or the
other if we decide that's ok.

- Although most Servlet dependencies have been removed from Page
Flow code, there's still a lot of *path* dependence.  The former should
disappear entirely; the latter is something we'll need to discuss.
There's a Chain step -- PopulatePageFlowContext -- that sets up a bunch
of Servlet-like attributes on the context, and this may go away 
eventually.


- *** There is currently no generation of XWork config files from
Page Flow classes/annotations.  All of the sample app config files
(/WEB-INF/src/_pageflow-config/**) are hand-coded.  Generation is a
well-known quantity, and I definitely expect the config file format to
change (especially after the XWork folks tell me how I've misused their
framework ;) ). ***

- Logging.  There's a Logger wrapper used throughout Page Flow.
This will most likely just go away ASAP.

- Controller classes still currently need to extend
PageFlowController.  This is a holdover from Beehive, but we'll change
it so that they can be POJOs.

- Page Flow doesn't use XWork's ability to create a form bean.  The
Page Flow version of this (ChooseFormBean) is currently totally distinct
from everything that happens in CreateFormChain.  It's a very different
process -- the form bean type is retrieved from config, not through
reflection; the scopes are currently "request" or "page flow" (the
latter get/set from member data in the page flow); etc., etc.  I just
didn't want to mess up what's there, but obviously we'll need to
consolidate.

- Page Flow has integration with Commons Validator (through
annotations), but this is not hooked up yet.  I know there's already
been work done in this area.

- Shared Flow support isn't enabled yet, although it's close.

- Page Flow isn't currently using the ActionMapper for creating
action URIs.

- The JSF sample still has "beehive" in its package names.

 - There are three temporary XMLBeans-generated jars that are
required for building the code.  I don't currently have access to my
people.apache.org account, so I put them out on cppdoc.com -- see
/project.properties.  They can be moved anywhere else (~mrdon?).
Event

[ti] first crack at Page Flow support

[Rich Feit]

Hi all,

Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbox).  It's basically Beehive Page Flow, minus
Struts 1.x, minus Servlet, plus XWork, plus some refactoring.  And minus
a bunch of functionality that I had to disable in the process.

There are three things here:
1) The patch itself.  There are notes below about this.

2) A sample app ("ti-example").  It's not integrated into the tree
at this point, but building/running should be easy:
   - 'maven war' in {ti root}/example, to get the right jars
for WEB-INF/lib.
   - Copy 
{ti-root}/example/target/struts-ti-example/WEB-INF/lib/*.jar into

ti-example/WEB-INF/lib.
   - Deploy ti-example, and (if you're using Tomcat), hit
http://localhost:8080/ti-example/pageflow .

3) Another sample app -- ported from Beehive -- to demonstrate JSF
integration in Struts Ti.  JSF is optional, but it's treated as a
first-class view tier.  JSF pages handle intra-page events, but raise
Page Flow actions for navigation.  The blurb at
http://beehive.apache.org/releases/v1.0m1/pageflow/jsf.html basically
applies here.  To build/run this, follow the steps for (2), and put
myfaces.jar (http://www.myfaces.org/) into WEB-INF/lib.  Then hit
http://localhost:8080/ti-jsf/ .

Note: I can't attach zip files here, so I've put the files at:
1) http://www.cppdoc.com/ti-temp/struts-ti-pageflow-patch.zip
2) http://www.cppdoc.com/ti-temp/ti-example.zip
3) http://www.cppdoc.com/ti-temp/ti-jsf.zip

If you have trouble connecting, let me know and I'll send them to you.


---
Everything below this line is mainly interesting if you're
working/peeking on the Ti source code.

- First, style.  I've given checkstyle a lot to complain about.  I
can work on fixing this (possibly with some discussion about a few of
the parameters) after this goes in -- I didn't want to wait any longer.
Apologies for the magnitude of angst I've caused.  :)

- All of the Page Flow code uses PageFlowActionContext, which is an
ActionContext that puts everything context-related in one place.  It
doesn't use ControllerContext.  Of course, in the end there will be one
thing, but I didn't want to blow up ControllerContext at this point
before having a discussion about how to rationalize all the contexts
(ActionContext, WebContext, Ti Context).

- I created a Chain for the View (kicked off by Servlet Filters).
This required splitting out some config code from StrutsTiServlet.

- Controller action methods and exception handlers currently return
either Forward (a convenience for adding view-setup objects to the
request) or String (simple result lookup).  We can eliminate one or the
other if we decide that's ok.

- Although most Servlet dependencies have been removed from Page
Flow code, there's still a lot of *path* dependence.  The former should
disappear entirely; the latter is something we'll need to discuss.
There's a Chain step -- PopulatePageFlowContext -- that sets up a bunch
of Servlet-like attributes on the context, and this may go away eventually.

- *** There is currently no generation of XWork config files from
Page Flow classes/annotations.  All of the sample app config files
(/WEB-INF/src/_pageflow-config/**) are hand-coded.  Generation is a
well-known quantity, and I definitely expect the config file format to
change (especially after the XWork folks tell me how I've misused their
framework ;) ). ***

- Logging.  There's a Logger wrapper used throughout Page Flow.
This will most likely just go away ASAP.

- Controller classes still currently need to extend
PageFlowController.  This is a holdover from Beehive, but we'll change
it so that they can be POJOs.

- Page Flow doesn't use XWork's ability to create a form bean.  The
Page Flow version of this (ChooseFormBean) is currently totally distinct
from everything that happens in CreateFormChain.  It's a very different
process -- the form bean type is retrieved from config, not through
reflection; the scopes are currently "request" or "page flow" (the
latter get/set from member data in the page flow); etc., etc.  I just
didn't want to mess up what's there, but obviously we'll need to
consolidate.

- Page Flow has integration with Commons Validator (through
annotations), but this is not hooked up yet.  I know there's already
been work done in this area.

- Shared Flow support isn't enabled yet, although it's close.

- Page Flow isn't currently using the ActionMapper for creating
action URIs.

- The JSF sample still has "beehive" in its package names.

 - There are three temporary XMLBeans-generated jars that are
required for building the code.  I don't currently have access to my
people.apache.org account, so I put them out on cppdoc.com -- see
/project.properties.  They can be moved anywhere else (~mrdon?).
Eventually these will go away.  If you have trouble connecting, let me
know and I'll send the jars.


Enjoy, and let me know what you