This has gone too far.
How Struts adds committers isn't "fair" - code quality, community involvement, trust, and yes, personal taste are all factors. The PMC members are the gate keepers, and being human, they show favoritism, bias, and sometimes poor judgment. You may not like it, but that's the way it is. Great. Can we move on now? Struts isn't some damn social club, where we sit around and gossip about the neighbors. Struts is about building great web frameworks, however, I feel we have strayed from this path and lost our focus. If we, committers and contributors alike, spent half the time committing code and contributing patches as we do bickering, complaining, and "offering our opinions", we'd be on Struts 4 by now! Let's stop this nonsense, and get back to work! Do you have too much free time on your hands? Great, there is much to be done: - Struts Action 1: We finally got the build working and have built a test build. I haven't heard a single comment from anyone who has downloaded it and given it a shot. If you want a stable Struts Action 1 release and more to come, get off your butt and help out! - Struts Action 2: With most of the IP code out of the way, we've started some great discussions on features to include in the next release. While this is important, we also need to get some sort of release out by JavaOne. We need people polishing up the code, updating wiki docs, testing examples, writing migration guides, and fixing bugs. - Tiles: For such a popular framework, it is a shame how few people contribute (only one active maintainer (!)). Greg is working on a standalone version of Tiles that would support Struts, Spring MVC, or anyone else. If you use Tiles, jump in and help Greg with the refactoring. We definitely will be looking for committers when this moves to Jakarta. - Struts Shale (yes it is an equal Struts project, get over it): There still hasn't been a GA release of Shale that I know of. We need people writing docs, fixing bugs, and providing key feedback to help polish this product. My personal thanks David Evens for helping out with JIRA, Wendy Smoak her hard work for the Maven 2 migration, Ted Husted for the Mailreader migration tutorial and training materials, Toby Jee for keeping up with bug fixes and working on the ww migration, Patrick Lightbody for the SAF 2 Maven 2 work, Phil Zoio for writing Strecksthese are people who stepped up to the plate and put their code where their mouth is. Let's grow this list! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] [VOTE] Target Java 5, support 1.4 through Retroweaver
When you say: "when you use a new method by mistake", are you refering to using API available only on 1.5? If so, this is a known problem, and indeed it is difficult to trap it. ./alex -- .w( the_mindstorm )p. On 4/26/06, netsql <[EMAIL PROTECTED]> wrote: > I have used retroweaver... and it does not work. (when you use a new > method by mistake). > > People that are on IBM or BEA old version can keep using old version of > Struts/WW2. > > When they upgrade to JEE5 then they can have more options. > > .V > > Jason Carreira wrote: > > +1 from me > > - > > Posted via Jive Forums > > http://forums.opensymphony.com/thread.jspa?threadID=27314&messageID=54288#54288 > > > - > 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: Java 1.4 support libraries (was [VOTE] Target Java 5, support
Annotations can be read at runtime only if accessing code and annotations are both translated with Retrotranslator. Taras > Interesting, separate jars were always in the plan, > so that isn't a problem. So you are saying the code > can still > access the annotations at runtime? > > Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=27314&messageID=54462#54462 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving JIRA issues to SHALE-xxx
Sorry about the flood (152 issues). One of the nice things that JIRA brings to the table is the ability to separate issues on a more fine-grained basis, and now was better than later for doing this (there will inevitably be more issues later :-). Craig
Re: [PROPOSAL] Separate lists for notifications vs. discussion
+1 ! Wendy Smoak schrieb: > To make it easier to filter and sort messages, and to facilitate > presenting the lists through alternate interfaces such as forums and > RSS feeds, I propose that we do the following: > > * establish [EMAIL PROTECTED] and direct JIRA emails to it > > * unsubscribe [EMAIL PROTECTED] (svn commit messages and Wiki diffs) from > dev@ > > Initially, the subscriber lists for these two could be copied from > dev@, so that current subscribers are not affected. (Except for > possibly needing to reconfigure mail filters.) > > Thanks, > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r397109 - /struts/site/src/site/xdoc/downloads.xml
Author: wsmoak Date: Tue Apr 25 23:45:09 2006 New Revision: 397109 URL: http://svn.apache.org/viewcvs?rev=397109&view=rev Log: Updated to reflect the latest project structure, added a link to Shale's nightly builds. Modified: struts/site/src/site/xdoc/downloads.xml Modified: struts/site/src/site/xdoc/downloads.xml URL: http://svn.apache.org/viewcvs/struts/site/src/site/xdoc/downloads.xml?rev=397109&r1=397108&r2=397109&view=diff == --- struts/site/src/site/xdoc/downloads.xml (original) +++ struts/site/src/site/xdoc/downloads.xml Tue Apr 25 23:45:09 2006 @@ -130,22 +130,15 @@ Use at your own risk! - -Apache Struts development builds are managed using -http://maven.apache.org/";>Apache Maven -. -Maven acquires the various JARs needed by Struts products -and automaticaly shares JARs between Struts subprojects -and other -Maven projects. - - -http://svn.apache.org/builds/struts/maven/";> -Nightly Builds -. +http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/";> +Action 1 Nightly Builds + + +http://cvs.apache.org/builds/struts/nightly/struts-shale/";> +Shale Nightly Builds @@ -173,8 +166,8 @@ -To download the trunk (HEAD revision) of any Struts -subproject, +To download the trunk (HEAD revision) of all Struts +subprojects, a convenience directory has been added, named current . @@ -222,23 +215,10 @@ - - http://svn.apache.org/repos/asf/struts/action/trunk -http://svn.apache.org/repos/asf/struts/apps/trunk -http://svn.apache.org/repos/asf/struts/el/trunk - -http://svn.apache.org/repos/asf/struts/faces/trunk -http://svn.apache.org/repos/asf/struts/flow/trunk - - http://svn.apache.org/repos/asf/struts/sandbox/trunk - - http://svn.apache.org/repos/asf/struts/scripting/trunk - -http://svn.apache.org/repos/asf/struts/shale/trunk - - http://svn.apache.org/repos/asf/struts/taglib/trunk - -http://svn.apache.org/repos/asf/struts/tiles/trunk + http://svn.apache.org/repos/asf/struts/action/trunk + http://svn.apache.org/repos/asf/struts/sandbox/trunk +http://svn.apache.org/repos/asf/struts/shale/trunk +http://svn.apache.org/repos/asf/struts/site @@ -285,7 +265,7 @@ we recommend that you install and use http://maven.apache.org";> Apache Maven -1.0.2, +2.0, since Maven will acquire whatever external JARs your system may need. Of course, @@ -295,11 +275,11 @@ -With Maven installed, building the entire Struts codebase +With Maven installed, building the entire Struts Action 1 codebase is as simple as -/current/build/> maven build-all +/current/action/> mvn install Maven will automatically download any dependencies as - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-145) [shale] Helper method for adding response headers and values
[ http://issues.apache.org/struts/browse/SHALE-145?page=all ] Craig McClanahan moved STR-2812 to SHALE-145: - Project: Shale (was: Struts Action 1) Key: SHALE-145 (was: STR-2812) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Helper method for adding response headers and values > > > Key: SHALE-145 > URL: http://issues.apache.org/struts/browse/SHALE-145 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > > When using Shale Remoting, it is often necessary for the handler to add HTTP > headers to the response. A utility method somewhere that abstracts away the > differences between the Servlet and Portlet APIs would be helpful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-146) Create Default Transitions for Dialogs
[ http://issues.apache.org/struts/browse/SHALE-146?page=all ] Craig McClanahan moved STR-2465 to SHALE-146: - Project: Shale (was: Struts Action 1) Key: SHALE-146 (was: STR-2465) Component: (was: Shale) Version: (was: 1.2.4) Assign To: (was: Struts Developer Mailing List) > Create Default Transitions for Dialogs > -- > > Key: SHALE-146 > URL: http://issues.apache.org/struts/browse/SHALE-146 > Project: Shale > Type: Improvement > Environment: Operating System: Mac OS X 10.3 > Platform: Macintosh > Reporter: David Geary > Priority: Minor > > We could make defining dialogs much easier with some default transitions. If > we > assume that the dialog states in dialog-config.xml are listed in the order > they > are traversed, we could provide default "next" and "previous" transitions for > each state, except of course, there would be no "previous" transition for the > first state, and no "next" transition for the previous state. Any explicit > "next" or "previous" states declared in dialog-config.xml would override the > defaults. > It also seems like a common requirement to have dialog-scope transitions (not > state-scope) for each state in the dialog. For example, many wizards have tabs > that let you jump from one wizard panel to the next, regardless of the > currently > displayed wizard panel. We could also create default dialog-scope transitions > whose outcomes and targets match the state names. Again, you could override > those defaults by providing your own transitions. > With those changes, we would reduce this: > >start="User Information"> > > > > > > viewId="/pages/account.jsp"> > target="Phone Numbers"/> > > viewId="/pages/account.jsp"> > target="Address"/> > target="User Information"/> > > viewId="/pages/account.jsp"> > target="Summary"/> > target="Phone Numbers"/> > > viewId="/pages/account.jsp"> > target="Address"/> > > viewId="/pages/login.jsp"> > > > > To this: > >start="User Information"> > viewId="/pages/account.jsp"/> > viewId="/pages/account.jsp"/> > viewId="/pages/account.jsp"/> > viewId="/pages/account.jsp"/> > viewId="/pages/login.jsp"> > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-137) [Shale][View] Event callbacks for servlet lifecycle events
[ http://issues.apache.org/struts/browse/SHALE-137?page=all ] Craig McClanahan moved STR-2720 to SHALE-137: - Project: Shale (was: Struts Action 1) Key: SHALE-137 (was: STR-2720) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale][View] Event callbacks for servlet lifecycle events > -- > > Key: SHALE-137 > URL: http://issues.apache.org/struts/browse/SHALE-137 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > Fix For: 1.0.1 > > ViewController provides application level event callbacks for classes that > implement that interface, but it would also be useful to support init/destroy > callbacks into objects that are inserted into, or removed from, any of the > servlet API scopes (request, session, application). This can be accompished > by > registerig a servlet listener that implements the servlet listener interfaces, > and triggers the appropriate callbacks. Exceptions from event handlers should > be handled consistently with the strategy devised for issue 38186. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-148) [shale] Additions to the mock objects
[ http://issues.apache.org/struts/browse/SHALE-148?page=all ] Craig McClanahan moved STR-2555 to SHALE-148: - Project: Shale (was: Struts Action 1) Key: SHALE-148 (was: STR-2555) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Additions to the mock objects > - > > Key: SHALE-148 > URL: http://issues.apache.org/struts/browse/SHALE-148 > Project: Shale > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: David Thielen > Priority: Minor > Attachments: ShaleMockObjects.zip > > I couldn't find a way to attach files so I placed them at > http://www.windward.net/ShaleMockObjects.zip - you should be able to just > replace the existing ones with these. > thanks - dave -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-152) [shale] RemoteCommand contains unused private method
[ http://issues.apache.org/struts/browse/SHALE-152?page=all ] Craig McClanahan moved STR-2644 to SHALE-152: - Project: Shale (was: Struts Action 1) Key: SHALE-152 (was: STR-2644) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] RemoteCommand contains unused private method > > > Key: SHALE-152 > URL: http://issues.apache.org/struts/browse/SHALE-152 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: sean schofield > Priority: Minor > Attachments: remotecommand_imports.patch > > The application() method does not seem to serve any purpose in this class. I > wanted to make sure its not being preserved for future use before removing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-149) [Shale] Support for fine grained security on navigation
[ http://issues.apache.org/struts/browse/SHALE-149?page=all ]
Craig McClanahan moved STR-2788 to SHALE-149:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-149 (was: STR-2788)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [Shale] Support for fine grained security on navigation
> ---
>
> Key: SHALE-149
> URL: http://issues.apache.org/struts/browse/SHALE-149
> Project: Shale
> Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Craig McClanahan
> Priority: Minor
>
> Conversations on the Struts user mailing list today highlight the potential
> for
> a Shale value add with regards to authorization. It was noted that container
> managed security can protect the incoming form submits, but does not protect
> navigation to an arbitrary page (because constraints are only applied on the
> initial submit, not on RequestDispatcher.forward() calls used to implement the
> navigation). It would be interesting for Shale to offer a customized
> navigation
> handler that would allow limitation of navigation to specified view
> identifiers
> based on request.isUserInRole().
> As a further generalization, it would be useful to present this capability as
> a
> general purpose plugin architecture, where the application could provide any
> sort of fine grained access control it wanted ("only managers can navigate to
> the salary details page, and only for their own employees"). A built in
> plugin
> that supported container managed security could be a "reference
> implementation"
> of this featue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-138) [Shale] Clay ComponentConfigBean should report missing id
[ http://issues.apache.org/struts/browse/SHALE-138?page=all ] Craig McClanahan moved STR-2770 to SHALE-138: - Project: Shale (was: Struts Action 1) Key: SHALE-138 (was: STR-2770) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay ComponentConfigBean should report missing id > - > > Key: SHALE-138 > URL: http://issues.apache.org/struts/browse/SHALE-138 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Hermod Opstvedt > Priority: Minor > > When testing clayForEach I inadvertendly misspelled the name in jsfid, which > gave me an exception: java.lang.NullPointerException: The component identified > by jsfid clayForeach could not be found. > It would be nice if ComponentConfigBean reported the erred value also. > Hermod -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-142) [shale] Dialog should allow flexible entry points
[ http://issues.apache.org/struts/browse/SHALE-142?page=all ] Craig McClanahan moved STR-2476 to SHALE-142: - Project: Shale (was: Struts Action 1) Key: SHALE-142 (was: STR-2476) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Dialog should allow flexible entry points > - > > Key: SHALE-142 > URL: http://issues.apache.org/struts/browse/SHALE-142 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: PC > Reporter: sean schofield > Priority: Minor > > It would be nice to be able to specify an entry point for a dialog. The > "start" > attribute is fine as a default but it would be nice to use an outcome such as > dialog:foo:step3 to jump right to apply the step3 transition. > This is useful if you have a series of dialogs with several steps (say 10 > steps) > and later on you want to edit only a portion of that information. If you had > this ability you could have a link or button that would launch the dialog > directly into the step that you wanted. I have some other ideas about > dynamically specifying the end state as well but I will save that for a later > bug report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-136) [shale] Implement support for a global XWork chain
[ http://issues.apache.org/struts/browse/SHALE-136?page=all ] Craig McClanahan moved STR-2829 to SHALE-136: - Project: Shale (was: Struts Action 1) Key: SHALE-136 (was: STR-2829) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Implement support for a global XWork chain > -- > > Key: SHALE-136 > URL: http://issues.apache.org/struts/browse/SHALE-136 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > > Shale provides an application controller (implemented as a filter) that > processes all requests to the application. It currenty supports the ability > to > customize the actual processing via a Commons Chain command chain. > Implement an optional enhancement to this controller that supports using an > XWork interceptor chain to provide customized processing on all requests to > the app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-150) [Shale] add base clay config to META-INF and added DTD documentation
[ http://issues.apache.org/struts/browse/SHALE-150?page=all ] Craig McClanahan moved STR-2453 to SHALE-150: - Project: Shale (was: Struts Action 1) Key: SHALE-150 (was: STR-2453) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] add base clay config to META-INF and added DTD documentation > > > Key: SHALE-150 > URL: http://issues.apache.org/struts/browse/SHALE-150 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: configPatch.zip > > I thought it might be nice to automatically register the base clay > configuration file, view-config.xml. I modified the logic to load the base > file from the META-INF, the same approach for registering a faces > configuration file. > I also put some documentation in the clay DTD. > M shale\clay-plugin\build.xml > M shale\clay-plugin\src\java\org\apache\shale\clay\configClayXmlParser.java > M shale\clay-plugin\src\java\org\apache\shale\clay\config\Globals.java > --Same file in two places > M shale\clay-plugin\src\conf\view-config.dtd > M shale\clay-plugin\src\java\org\apache\shale\clay\config\resources\clay- > config_1_0.dtd > M shale\clay-plugin\src\conf\view-config.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-141) [Shale] "beefed up" the Clay HTML parser
[ http://issues.apache.org/struts/browse/SHALE-141?page=all ] Craig McClanahan moved STR-2446 to SHALE-141: - Project: Shale (was: Struts Action 1) Key: SHALE-141 (was: STR-2446) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] "beefed up" the Clay HTML parser > > > Key: SHALE-141 > URL: http://issues.apache.org/struts/browse/SHALE-141 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: diff.log, parserPatch.zip > > I've "beefed up" the clay parser to better handle > full html documents in preparation of a custom > ViewHandler. > M Parser.java (Blocks 34496 for this one file only) > A TestParser.java > Created a new junit test case for the following scenarios: > 1) Tests to see if we can parse a document >fragment that has multiple root nodes. > 2) Test a few comment block scenarios. > 3) Tests case insensitivity in parsing the document. > 4) Tests the parsing to make sure that self terminated >nodes are handled the same as well-formed self >terminating nodes > 5) Tests to make sure that the parser handles the HTML >tags that can have optional ending tags the same that >it would a document that was well-formed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-151) [Shale][View] Refactor ShaleViewHandler
[ http://issues.apache.org/struts/browse/SHALE-151?page=all ] Craig McClanahan moved STR-2718 to SHALE-151: - Project: Shale (was: Struts Action 1) Key: SHALE-151 (was: STR-2718) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale][View] Refactor ShaleViewHandler > --- > > Key: SHALE-151 > URL: http://issues.apache.org/struts/browse/SHALE-151 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > Fix For: 1.0.1 > > In preparation for implementing shale-tiger (with annotations) support for > view > controller functionality that does not require the application class to > actually > implement the ViewController interface, some refactoring is necessary. Among > the steps to perform are: > * Create new "org.apache.shale.view.faces" package > for the JSF integration of view controller support > (parallel to what happens for dialog and remoting). > * Move ShalePhaseListener and ShaleViewController to > the new package, renaming them to something specific > to "view" in their names. > * Refactor the current code in ShaleViewController and > ShalePhaseListener so that "view controller" instances > can be instantiated, and event callbacks performed, > even if the object class does not implement ViewController. > * The callback logic, in particular, should be generalized > so that it can be used for other types of callbacks (via > interfaces in Shale Core, via annotations with shale-tiger) > yet to be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-140) [shale] Remoting should set cache-disabling headers on dynamic calls
[ http://issues.apache.org/struts/browse/SHALE-140?page=all ] Craig McClanahan moved STR-2821 to SHALE-140: - Project: Shale (was: Struts Action 1) Key: SHALE-140 (was: STR-2821) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Remoting should set cache-disabling headers on dynamic calls > > > Key: SHALE-140 > URL: http://issues.apache.org/struts/browse/SHALE-140 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > > Currently, Shale Remoting's support for dynamic calls (mapped to a method > binding expression) expressly skip setting a Date header on the corresponding > response. In theory, this should avoid the browser caching previous responses > for the same URL -- but apparently some versions of IE do this caching anyway. > Suggestion is to have the Processor for dynamic responses emit the same > headers > that Struts 1.x does when "no-cache" support is requested: > Pragma: No-Cache > Cache-Control: no-cache,no-store,max-age-0 > Expires: <<>> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-121) Remote Method Call Simplification
[ http://issues.apache.org/struts/browse/SHALE-121?page=all ] Craig McClanahan moved STR-2708 to SHALE-121: - Project: Shale (was: Struts Action 1) Key: SHALE-121 (was: STR-2708) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Remote Method Call Simplification > - > > Key: SHALE-121 > URL: http://issues.apache.org/struts/browse/SHALE-121 > Project: Shale > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: David Geary > Priority: Minor > > Decouple Shale remote method calls from Commons Chain. As it stands, to > invoke a remote method > call, a developer must: > 1. Implement a Jakarta Commons Chain command. > 2. Add an entry to the remote catalog for your command in chain-config.xml. > 3. Invoke the appropriate URL using JavaScript. > This dependency on Chain is largely artificial, and induces another layer > that developers > must understand and configure just to make a remote method call. > Steps 1&2 can be eliminated by getting rid of the Chain command requirement > and instead invoking > methods on managed beans using reflection. Sort of a remote value binding. > Note: The point here is not whether using Chain commands for remote method > calls is a good thing, > but whether developers should be forced to use it. This enhancement is also > about simplifying remote > method calls by removing the Chain requirement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-143) [Shale] Enhancement to the Shale subview tag library component.
[ http://issues.apache.org/struts/browse/SHALE-143?page=all ] Craig McClanahan moved STR-2381 to SHALE-143: - Project: Shale (was: Struts Action 1) Key: SHALE-143 (was: STR-2381) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: David Evans) > [Shale] Enhancement to the Shale subview tag library component. > --- > > Key: SHALE-143 > URL: http://issues.apache.org/struts/browse/SHALE-143 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: PC > Reporter: Gary VanMatre > Priority: Minor > Attachments: ClayWeb.zip, ClayWeb.zip, ClayWeb.zip, clay-plugin-04-09.zip, > soda_example_war.zip, subview-example.zip > > The shale subview jsf component provides a post back method to the prerender > method on the ViewController. The id attribute of the component is assumed > as > the managed bean name. This method would be very useful for staging data for > the subview. > I would like to introduce a subclass of the subview tag that would allow > constructing fragments of a page using a XML definition. Like tiles, the > metadata defining the subcomponent tree would support generalization > inheritances and also composition inheritance. It would also allow a token > replacement feature of the binding EL so that the metadata describing the > construction of a subcomponent tree could be reused on multiple managed bean > names. > I have a prototype of this component integrated in with Shale and using the > myfaces implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-131) [shale] Support for variable "var" validation parameters
[ http://issues.apache.org/struts/browse/SHALE-131?page=all ]
Craig McClanahan moved STR-2782 to SHALE-131:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-131 (was: STR-2782)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [shale] Support for variable "var" validation parameters
>
>
> Key: SHALE-131
> URL: http://issues.apache.org/struts/browse/SHALE-131
> Project: Shale
> Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Hubert Rabago
> Priority: Minor
>
> The Commons Validator support specifies validation "var"s as tag attributes:
> datePatternStrict="MM/dd/"
> arg="#{messages['prompt.expirationDate']}"
> server="true"
> client="true"/>
> 'datePatternStrict' is a parameter for the date validator. Other validators
> have other parameters. The support can be enhanced by specifying parameters
> using another tag:
> arg="#{messages['prompt.expirationDate']}"
> server="true"
> client="true">
>
>
> This allows custom validators to use their own parameters, or updated versions
> of the built-in validators to use new parameters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-129) [Shale] Struts Website Features
[ http://issues.apache.org/struts/browse/SHALE-129?page=all ] Craig McClanahan moved STR-2498 to SHALE-129: - Project: Shale (was: Struts Action 1) Key: SHALE-129 (was: STR-2498) Component: (was: Web Site) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Struts Website Features > --- > > Key: SHALE-129 > URL: http://issues.apache.org/struts/browse/SHALE-129 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: features.patch > > Created a few paragraphs on Clay features. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-144) [shale] Default validator configuration should include rules
[ http://issues.apache.org/struts/browse/SHALE-144?page=all ] Craig McClanahan moved STR-2706 to SHALE-144: - Project: Shale (was: Struts Action 1) Key: SHALE-144 (was: STR-2706) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Default validator configuration should include rules > > > Key: SHALE-144 > URL: http://issues.apache.org/struts/browse/SHALE-144 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Wendy Smoak > Priority: Minor > Attachments: validator.diff > > The oas.validator.CommonsValidator clas currently loads the validation rules > from > /WEB-INF/validator-rules.xml, (and the messages from > /org/apache/shale/validator/messages.properties). > Instead of making the user responsible for providing the default > validation-rules.xml file, we can include it in shale-core.jar, and change > CommonsValidator to load it from there. Validation will then work with no > intervention. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-147) Identify action paths
[ http://issues.apache.org/struts/browse/SHALE-147?page=all ] Craig McClanahan moved STR-2642 to SHALE-147: - Project: Shale (was: Struts Action 1) Key: SHALE-147 (was: STR-2642) Component: (was: Action) Version: (was: 1.3.0) Assign To: (was: Struts Developer Mailing List) > Identify action paths > - > > Key: SHALE-147 > URL: http://issues.apache.org/struts/browse/SHALE-147 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Paul Benedict > Priority: Minor > Attachments: patch.txt, patch.txt > > Many times I need to redirect to another Struts actions. Recently I've come > across the problem of needing to rename my action paths but this became a real > nightmare to keep the action names as well as my redirect (forward) paths in > synchronization. > I propose adding an id attribute to the tag so that it can be > referred > to in tags and its URL would be inferred, rather than be explicitly > listed out. I find this proposal also to work well as a replacement for global > forwards. > > ... > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-124) [Shale] Added tapestry like example to the roledex usecase
[ http://issues.apache.org/struts/browse/SHALE-124?page=all ] Craig McClanahan moved STR-2515 to SHALE-124: - Project: Shale (was: Struts Action 1) Key: SHALE-124 (was: STR-2515) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Added tapestry like example to the roledex usecase > -- > > Key: SHALE-124 > URL: http://issues.apache.org/struts/browse/SHALE-124 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: RolodexTestCase.java, address.html, address.html, rolodex.patch > > The attached patch features Clay's Tapestry like templating feature. All > three of Clay's composition techniques will be featured in the rolodex > usecase > now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-117) [Shale] Clay ForEach component
[ http://issues.apache.org/struts/browse/SHALE-117?page=all ] Craig McClanahan moved STR-2675 to SHALE-117: - Project: Shale (was: Struts Action 1) Key: SHALE-117 (was: STR-2675) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay ForEach component > -- > > Key: SHALE-117 > URL: http://issues.apache.org/struts/browse/SHALE-117 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > > There has been some recent discussion on the possibility of a Clay ForEach > component. I wanted to post this as a proposed solution and solicit feedback > before committing it. I've attached a few pages that can be dropped into the > rolodex usecase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-130) [shale] Add documentation for "tiles" and "remoting" features
[ http://issues.apache.org/struts/browse/SHALE-130?page=all ] Craig McClanahan moved STR-2662 to SHALE-130: - Project: Shale (was: Struts Action 1) Key: SHALE-130 (was: STR-2662) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] Add documentation for "tiles" and "remoting" features > - > > Key: SHALE-130 > URL: http://issues.apache.org/struts/browse/SHALE-130 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > > The feature documentation pages for these two topices are currently > placeholders, and need to be fleshed out in a format similar to the other > sections (Introduction, Services Provided, and Using XXX). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-125) [Shale][View] Devise coherent exception handling strategy
[ http://issues.apache.org/struts/browse/SHALE-125?page=all ] Craig McClanahan moved STR-2719 to SHALE-125: - Project: Shale (was: Struts Action 1) Key: SHALE-125 (was: STR-2719) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale][View] Devise coherent exception handling strategy > - > > Key: SHALE-125 > URL: http://issues.apache.org/struts/browse/SHALE-125 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > Fix For: 1.0.1 > > Handling of exceptions from application event handlers is currently ad hoc, > and > does not always guarantee that ViewController contracts will be fulfilled. We > need a general strategy for handling such exceptions that fulfills contracts, > and offers application developers some choices in how they are handled > (ignore, > log only, log and rethrow, log and accumulate into an exception thrown at the > end of the request). > Along the way, ensure that issue 38000 in particular gets addressed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-139) [Shale] Make the current dialog state available to applications
[ http://issues.apache.org/struts/browse/SHALE-139?page=all ]
Craig McClanahan moved STR-2444 to SHALE-139:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-139 (was: STR-2444)
Component: (was: Shale)
Version: (was: Unknown)
Assign To: (was: Struts Developer Mailing List)
> [Shale] Make the current dialog state available to applications
> ---
>
> Key: SHALE-139
> URL: http://issues.apache.org/struts/browse/SHALE-139
> Project: Shale
> Type: Improvement
> Environment: Operating System: Mac OS X 10.3
> Platform: Macintosh
> Reporter: David Geary
> Priority: Minor
>
> Currently, applications can access the current dialog's status via a Status
> object that Shale stores in session scope. But the dialog state is buried
> inside
> that status in a Status.Position object that's inaccessible outside of the
> Shale
> dialog package. That means applications cannot programatically determine the
> current state of a dialog.
> Sometimes it's important for backing beans to determine state. For example, I
> have a wizard based on one JSP page. That page has one h:panelGrid for each
> panel in the wizard, but only one grid is displayed at a time with the
> rendered
> attribute:
> ...
> ...
> ...
> ...
> My backing bean's isAddressPanelRendered and isPhonePanelRendered methods need
> to know the current dialog state. I'd be happy with these additions to
> Status.java:
> public String getDialogName() {
> return peek().getDialogName();
> }
> public String getStateName() {
> return peek().getStateName();
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-122) [shale] Organize imports
[ http://issues.apache.org/struts/browse/SHALE-122?page=all ] Craig McClanahan moved STR-2645 to SHALE-122: - Project: Shale (was: Struts Action 1) Key: SHALE-122 (was: STR-2645) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Organize imports > > > Key: SHALE-122 > URL: http://issues.apache.org/struts/browse/SHALE-122 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Priority: Minor > Attachments: shale_core_imports.patch, shale_test_imports.patch, > shale_usecases_imports.patch > > Patches follow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-119) [shale] Add spring like syntax for loading clay configs from classpath
[ http://issues.apache.org/struts/browse/SHALE-119?page=all ] Craig McClanahan moved STR-2717 to SHALE-119: - Project: Shale (was: Struts Action 1) Key: SHALE-119 (was: STR-2717) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Add spring like syntax for loading clay configs from classpath > -- > > Key: SHALE-119 > URL: http://issues.apache.org/struts/browse/SHALE-119 > Project: Shale > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: Ryan Wynn > Priority: Minor > > Clay loads configuration files from the classpath if the value is prefixed > with 'META-INF' > This enhancement requests that a spring like notation be used to load > configurations from the classpath. > > clay-config-files > > classpath*:/META-INF/classpath-config.xml > > > This way configurations can be loaded from any package. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-126) [Shale] Clay was not setting properties correctly
[ http://issues.apache.org/struts/browse/SHALE-126?page=all ] Craig McClanahan moved STR-2448 to SHALE-126: - Project: Shale (was: Struts Action 1) Key: SHALE-126 (was: STR-2448) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay was not setting properties correctly > - > > Key: SHALE-126 > URL: http://issues.apache.org/struts/browse/SHALE-126 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: PropUtilTest.java, propPatch.zip > > The PropertyUtil class was not working for all properties. This utility > class > is used by the clay component to set property values on faces components, > converters, validators and listeners. The utility has to take the string > value and figure out what the target type should be. I had pulled this from > another project and it was just not working right with the clay component so > I've refactored, removing unnecessary logic. > The logic now makes some guesses on setter methods and the formal parameter > type of the setter method. > > For example the following properties will all result in setting the boolean: > globalOnly > isGlobalOnly > escape > isEscape > > Two class are modified both blocking 34496 for each source file. > PropUtils.java > PropertyValueCommand.java > I had forgot this class was such a mess. It is a very important part in > making clay work. Any ideas on a better approach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-118) [Shale] test cases for the lookup usecase
[ http://issues.apache.org/struts/browse/SHALE-118?page=all ] Craig McClanahan moved STR-2472 to SHALE-118: - Project: Shale (was: Struts Action 1) Key: SHALE-118 (was: STR-2472) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] test cases for the lookup usecase > - > > Key: SHALE-118 > URL: http://issues.apache.org/struts/browse/SHALE-118 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: ListCategoriesTestCase.java, ListCategoriesTestCase.java, > ListLocalesTestCase.java, ListLocalesTestCase.java > > A couple simple test cases to exercise the features in the view controller's > of the lookup use case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-123) Enhancement to Shale Dialogs
[ http://issues.apache.org/struts/browse/SHALE-123?page=all ] Craig McClanahan moved STR-2735 to SHALE-123: - Project: Shale (was: Struts Action 1) Key: SHALE-123 (was: STR-2735) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Enhancement to Shale Dialogs > > > Key: SHALE-123 > URL: http://issues.apache.org/struts/browse/SHALE-123 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Matthias Wessendorf > Priority: Minor > Attachments: InitDialogPhaseListener.java > > As discussed on struts-dev list, here is an enhancement request to init > dialogs > by a programmatic way. > Here is my email to struts-dev: > 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 (e.g. > ) > *after* a user logs into that application? > -Matthias -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-120) [shale] Allow for classname attribute in dialog-config.xml
[ http://issues.apache.org/struts/browse/SHALE-120?page=all ] Craig McClanahan moved STR-2520 to SHALE-120: - Project: Shale (was: Struts Action 1) Key: SHALE-120 (was: STR-2520) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Allow for classname attribute in dialog-config.xml > -- > > Key: SHALE-120 > URL: http://issues.apache.org/struts/browse/SHALE-120 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: sean schofield > Priority: Minor > Attachments: shale.patch > > Currently its impossible to use your own implementation of Dialog without also > providing your own configuration class. In many cases the custom class may > only > involve a few extra "setter" properties and therefore could use 99% of the > code > in Configuration Init. > For this usecase it would be nice to be able to specify an optional > "classname" > attribute so that Digester can create classes other than DialogImpl. The > default should still be DialogImpl and so there would be no need to change > existing dialog-config.xml files for users who are using the default > implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-96) Remoting Doesn't work with the RI build
[ http://issues.apache.org/struts/browse/SHALE-96?page=all ] Craig McClanahan moved STR-2723 to SHALE-96: Project: Shale (was: Struts Action 1) Key: SHALE-96 (was: STR-2723) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Remoting Doesn't work with the RI build > --- > > Key: SHALE-96 > URL: http://issues.apache.org/struts/browse/SHALE-96 > Project: Shale > Type: Bug > Environment: Operating System: Mac OS X 10.4 > Platform: All > Reporter: David Geary > > Remoting only works with the MyFaces build. With the RI, clicking on the > remoting links in the usecases application results in an exception. > Thanks to Gary VanMatre for helping me dig this up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-116) [Shale] Messages should log warning if name not found
[ http://issues.apache.org/struts/browse/SHALE-116?page=all ]
Craig McClanahan moved STR-2761 to SHALE-116:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-116 (was: STR-2761)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [Shale] Messages should log warning if name not found
> -
>
> Key: SHALE-116
> URL: http://issues.apache.org/struts/browse/SHALE-116
> Project: Shale
> Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Hermod Opstvedt
> Priority: Minor
>
> public String getMessage(String key, Locale locale) {
> ResourceBundle rb = getBundle(locale);
> try {
> return rb.getString(key);
> } catch (MissingResourceException e) {
> + Log.warn("Name : " + key + " not found in bundle");
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-109) [Shale] Added Clay full-view HTML Tapestry like composition
[ http://issues.apache.org/struts/browse/SHALE-109?page=all ] Craig McClanahan moved STR-2518 to SHALE-109: - Project: Shale (was: Struts Action 1) Key: SHALE-109 (was: STR-2518) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Added Clay full-view HTML Tapestry like composition > --- > > Key: SHALE-109 > URL: http://issues.apache.org/struts/browse/SHALE-109 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: ClayViewHandler.java, clay.patch, hrolodex.html, usecase.patch > > The following patch provides full HTML tapestry like support using the Clay > component. A custom ViewHandler is registered that intercepts resources with > a matching URL suffix. Besides the new ClayViewHandler there are a couple > other bug fixes and enhancements to accommodate the new feature. > > There is also a patch for the rolodex use case showing the same example using > the new full-view HTML templating mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-132) Shale should be able to resolve parameters in navigation rules
[ http://issues.apache.org/struts/browse/SHALE-132?page=all ]
Craig McClanahan moved STR-2824 to SHALE-132:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-132 (was: STR-2824)
Component: (was: Shale)
Version: (was: Unknown)
Assign To: (was: Struts Developer Mailing List)
> Shale should be able to resolve parameters in navigation rules
> --
>
> Key: SHALE-132
> URL: http://issues.apache.org/struts/browse/SHALE-132
> Project: Shale
> Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Hermod Opstvedt
> Priority: Minor
>
> Given a navigation rule:
>
> /someview.xml
>
> marathonside
> /anotherview.xml?arrid=#{pages$mybean.arrid} id>
>
>
>
> Shale should be able to resolve the parameter #{pages$mybean.arrid} so that
> when
> the new page gets rendered, it can query for the requestparamter.
> This would greatly enhance Shale and ease parameter exchange between pages i.e
> backingbeans.
> Hermod
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-107) [shale] Test case for TokenProcessor fails
[ http://issues.apache.org/struts/browse/SHALE-107?page=all ] Craig McClanahan moved STR-2586 to SHALE-107: - Project: Shale (was: Struts Action 1) Key: SHALE-107 (was: STR-2586) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] Test case for TokenProcessor fails > -- > > Key: SHALE-107 > URL: http://issues.apache.org/struts/browse/SHALE-107 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: patch.diff > > If we look at the used timestamps the problem is obvious. > Iteration 6 > System.currentTimeMillis() : 1126941502165 > previous ..: 1126941502155 > current ...: 1126941502165 > Iteration 7 > System.currentTimeMillis() : 1126941502165 > previous ..: 1126941502165 > current ...: 1126941502166 > Iteration 8 > System.currentTimeMillis() : 1126941502165 > previous ..: 1126941502166 > current ...: 1126941502165 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-98) [Shale] The shale-blank application includes extra jars in WEB-INF/lib
[ http://issues.apache.org/struts/browse/SHALE-98?page=all ] Craig McClanahan moved STR-2798 to SHALE-98: Project: Shale (was: Struts Action 1) Key: SHALE-98 (was: STR-2798) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] The shale-blank application includes extra jars in WEB-INF/lib > -- > > Key: SHALE-98 > URL: http://issues.apache.org/struts/browse/SHALE-98 > Project: Shale > Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Ryan Lubke > > If one deploys the shale-blank application to GlassFish and issue a request to > the context-root, the following exception is returned: > java.lang.IllegalStateException: No WebApplicationContext found: no > ContextLoaderListener registered? >at > org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationContext(FacesContextUtils.java:78) >at > org.springframework.web.jsf.DelegatingVariableResolver.getWebApplicationContext(DelegatingVariableResolver.java:134) >at > org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:112) >at > org.apache.shale.spring.WebApplicationContextVariableResolver.resolveVariable(WebApplicationContextVariableResolver.java:87) >at > com.sun.faces.el.VariableResolverChainWrapper.getValue(VariableResolverChainWrapper.java:71) >at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-133) [Shale] "Extend shale-test-framework to support rendering JSF pages outside a container"
[ http://issues.apache.org/struts/browse/SHALE-133?page=all ] Craig McClanahan moved STR-2832 to SHALE-133: - Project: Shale (was: Struts Action 1) Key: SHALE-133 (was: STR-2832) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale] "Extend shale-test-framework to support rendering JSF pages outside a > container" > > > Key: SHALE-133 > URL: http://issues.apache.org/struts/browse/SHALE-133 > Project: Shale > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: Lasse Koskela > Priority: Minor > > It would be nice to be able to render JSF pages along with standard and custom > components in similar manner to what JspTest (http://jsptest.sf.net) provides > for regular JSPs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-127) [Shale] Add Dialog-scoped Transitions
[ http://issues.apache.org/struts/browse/SHALE-127?page=all ] Craig McClanahan moved STR-2445 to SHALE-127: - Project: Shale (was: Struts Action 1) Key: SHALE-127 (was: STR-2445) Component: (was: Shale) Version: (was: 1.2.4) Assign To: (was: Struts Developer Mailing List) > [Shale] Add Dialog-scoped Transitions > - > > Key: SHALE-127 > URL: http://issues.apache.org/struts/browse/SHALE-127 > Project: Shale > Type: Improvement > Environment: Operating System: Mac OS X 10.3 > Platform: Macintosh > Reporter: David Geary > Priority: Minor > > In practice, transitions are frequently applied to all states in a dialog; for > example, you might have menu links that are hardwired to wizard panels. The > transitions associated with those links are applicable regardless of the > wizard's state (IOW, they are scoped to all states in a dialog). > Currently Shale only supports transitions scoped to a single dialog state. I > would like to see transitions that are automatically applied to all of a > dialog's states: > > > > > > > > > ... > > > Currently, you can make a transition applicable to all of a dialog's states by > copying and pasting the transition into every state. But that violates the DRY > principle, is error prone and tedious, and makes dialog-config.xml difficult > to > read. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-97) [Shale] The shale-blank application should enable Spring support by default.
[ http://issues.apache.org/struts/browse/SHALE-97?page=all ] Craig McClanahan moved STR-2797 to SHALE-97: Project: Shale (was: Struts Action 1) Key: SHALE-97 (was: STR-2797) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] The shale-blank application should enable Spring support by default. > > > Key: SHALE-97 > URL: http://issues.apache.org/struts/browse/SHALE-97 > Project: Shale > Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Ryan Lubke > > Please provide details here. Its best to submit patches that alter > existing file content in "unified cvs diff" format. > Submissions that provide new files can be supplied as direct file > attachments or archives in zip or tar.gz format. please be kind > enough to identify the format of the attached archive as bugzilla > tends to strip these characterstics by removing the files extension. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-108) [shale] Implement support for XWork chains by replacing default ActionListener
[ http://issues.apache.org/struts/browse/SHALE-108?page=all ] Craig McClanahan moved STR-2828 to SHALE-108: - Project: Shale (was: Struts Action 1) Key: SHALE-108 (was: STR-2828) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Implement support for XWork chains by replacing default ActionListener > -- > > Key: SHALE-108 > URL: http://issues.apache.org/struts/browse/SHALE-108 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > > JSF provides an extension point for replacing the default ActionListener > implementation that actually invokes the action method when an ActionEvent is > fired, say, for a form submit. This corresponds to the point at which an > action > oriented framework would invoke the "execute" (or whatever) method on the > selected action instance. > Implement an optional replacement for the default ActionListener that would > invoke an XWork interceptor chain around the invocation of the execute > method. > This would allow per-action customization of the actual processing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-134) [Shale][Tiger] Implement event callbacks via annotations
[ http://issues.apache.org/struts/browse/SHALE-134?page=all ] Craig McClanahan moved STR-2722 to SHALE-134: - Project: Shale (was: Struts Action 1) Key: SHALE-134 (was: STR-2722) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale][Tiger] Implement event callbacks via annotations > > > Key: SHALE-134 > URL: http://issues.apache.org/struts/browse/SHALE-134 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > Fix For: 1.0.1 > > Extend the capability of the servlet event callbacks implemented per issue > 38187 > to work with classes that mark init and destroy methods with annotations, not > just those that implement a specific interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-128) Shale tiger extension inside jboss, library path config
[ http://issues.apache.org/struts/browse/SHALE-128?page=all ]
Craig McClanahan moved STR-2814 to SHALE-128:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-128 (was: STR-2814)
Component: (was: Shale)
Version: (was: Unknown)
Assign To: (was: Struts Developer Mailing List)
> Shale tiger extension inside jboss, library path config
> ---
>
> Key: SHALE-128
> URL: http://issues.apache.org/struts/browse/SHALE-128
> Project: Shale
> Type: Improvement
> Environment: Operating System: All
> Platform: Other
> Reporter: Grigoras Cristinel
> Priority: Minor
>
> Inside JBOSS server the library location is not only WEB-INF/lib.
> Maybe init parameter to change lib search location will be very good.
> In the View annotation class , why you not asign the value of view id ?
> and bean name for view ?
> something like @View(viewId="/sec/test.jsp",name="sec$test") or more extended
> @Views( [EMAIL PROTECTED](...),@View{...}} ?
> How can i change default maping ?
> Cristi
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-100) shale-mailreader-20060316.war could not be started
[ http://issues.apache.org/struts/browse/SHALE-100?page=all ] Craig McClanahan moved STR-2801 to SHALE-100: - Project: Shale (was: Struts Action 1) Key: SHALE-100 (was: STR-2801) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > shale-mailreader-20060316.war could not be started > -- > > Key: SHALE-100 > URL: http://issues.apache.org/struts/browse/SHALE-100 > Project: Shale > Type: Bug > Environment: Operating System: Linux > Platform: PC > Reporter: Mark Shifman > > When trying to deploy shale-mailreader-20060316.war, I got the message > FAIL - Application at context path /shale-mailreader-20060316 could not be > started > I am using Apache Tomcat/5.0.19and JVM version 1.4.2_02-b03 > 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003 i686 i686 i386 GNU/Linux > I also get this error: > 2006-03-16 15:29:03 StandardContext[/shale-mailreader-20060316]Exception > starting filter shale > java.lang.UnsupportedClassVersionError: > org/apache/shale/tiger/faces/LifecycleListener (Unsupported major.minor > version > 49.0) > When I removed shale-tiger.jar from the WEB-INF/lib (as suggested by Wendy > Smoak) the application starts and runs fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-115) [Shale][Tiger] Implement view controller via annotations
[ http://issues.apache.org/struts/browse/SHALE-115?page=all ] Craig McClanahan moved STR-2721 to SHALE-115: - Project: Shale (was: Struts Action 1) Key: SHALE-115 (was: STR-2721) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale][Tiger] Implement view controller via annotations > > > Key: SHALE-115 > URL: http://issues.apache.org/struts/browse/SHALE-115 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > Priority: Minor > Fix For: 1.0.1 > > In the shale-tiger library (where JavaSE 5 can be assumed), implement support > for view controller callbacks on classes that do not implement ViewController, > but mark the appropriate classes and methods with annotations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-102) [shale][use-cases] Remote commands doesn't work anymore
[ http://issues.apache.org/struts/browse/SHALE-102?page=all ] Craig McClanahan moved STR-2560 to SHALE-102: - Project: Shale (was: Struts Action 1) Key: SHALE-102 (was: STR-2560) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale][use-cases] Remote commands doesn't work anymore > --- > > Key: SHALE-102 > URL: http://issues.apache.org/struts/browse/SHALE-102 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: patch.diff > > Craig, with revision 234439 you have removed the remote command processing > which makes the 'Java Based Remoting Support' useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-135) [Shale] Clay ForEach component
[ http://issues.apache.org/struts/browse/SHALE-135?page=all ] Craig McClanahan moved STR-2674 to SHALE-135: - Project: Shale (was: Struts Action 1) Key: SHALE-135 (was: STR-2674) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay ForEach component > -- > > Key: SHALE-135 > URL: http://issues.apache.org/struts/browse/SHALE-135 > Project: Shale > Type: Improvement > Environment: Operating System: Windows XP > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: ForEach.patch, foreach.html, statesList.html, statesPanel.html > > There has been some recent discussion on the possibility of a Clay ForEach > component. I wanted to post this as a proposed solution and solicit feedback > before committing it. I've attached a few pages that can be dropped into the > rolodex usecase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-101) Add Java Doc to may source files and add more Tapestry like support
[ http://issues.apache.org/struts/browse/SHALE-101?page=all ] Craig McClanahan moved STR-2428 to SHALE-101: - Project: Shale (was: Struts Action 1) Key: SHALE-101 (was: STR-2428) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Add Java Doc to may source files and add more Tapestry like support > > > Key: SHALE-101 > URL: http://issues.apache.org/struts/browse/SHALE-101 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Attachments: diff.txt > > Many of the source files didn't have javadoc. The html and > tags didn't have tapestry like binding. > An example follows: > HTML Fragment: > > >Notice > > > >data for mockup > > > > XML Config Fragment: > > componentType="javax.faces.HtmlInputTextarea"/> > > >value="http://www.globalsecurity.org/wmd/systems/ebs.htm"/> > > > > > > > > > added java doc > M component/chain/PropertyValueCommand.java > M component/chain/PropertyActionCommand.java > M component/chain/PropertyActionListenerCommand.java > M component/chain/PropertyValidatorCommand.java > M component/chain/PropertyValueChangeListenerCommand.java > changed getElementId() to getJsfid() and added java doc > M parser/Node.java > M parser/builder/SelectManyMenuBuilder.java > M parser/builder/chain/SpanBuilderRule.java > M parser/builder/chain/FormBuilderRule.java > M parser/builder/chain/BuilderRuleContext.java > M parser/builder/chain/DefaultBuilderRule.java > M parser/builder/chain/OptionBuilderRule.java > M parser/builder/chain/InputBuilderRule.java > M parser/builder/chain/LabelBuilderRule.java > M parser/builder/chain/SelectBuilderRule.java > M parser/builder/SelectItemBuilder.java > M parser/builder/OutputLabelBuilder.java > M parser/builder/SelectOneRadioBuilder.java > M parser/builder/FormBuilder.java > M parser/builder/InputTextBuilder.java > M parser/builder/SelectOneMenuBuilder.java > M parser/builder/BuilderFactory.java > M parser/builder/VerbatimBuilder.java > M parser/builder/CommandButtonBuilder.java > M parser/builder/Builder.java > M parser/builder/SelectItemsBuilder.java > M parser/builder/MorphBuilder.java > M parser/builder/SelectBooleanCheckboxBuilder.java > registered two new builder rules > M parser/builder/chain/shale-builder-config.xml > Added two new builder and associated rules > A parser/builder/OutputLinkBuilder.java > A parser/builder/InputTextareaBuilder.java > A parser/builder/chain/AnchorBuilderRule.java > A parser/builder/chain/TextareaBuilderRule.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-88) [shale] AbstractFacesBean: using own convenience accessors
[ http://issues.apache.org/struts/browse/SHALE-88?page=all ] Craig McClanahan moved STR-2766 to SHALE-88: Project: Shale (was: Struts Action 1) Key: SHALE-88 (was: STR-2766) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] AbstractFacesBean: using own convenience accessors > -- > > Key: SHALE-88 > URL: http://issues.apache.org/struts/browse/SHALE-88 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Matthias Wessendorf > Priority: Minor > Attachments: abstractFacesBean > > AbstractFacesBean is now some convenience accessors (like getFacesContext()) > instead of FacesCxt.getcurrentInstance() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-99) [shale] small patch for the buildfiles
[ http://issues.apache.org/struts/browse/SHALE-99?page=all ] Craig McClanahan moved STR-2559 to SHALE-99: Project: Shale (was: Struts Action 1) Key: SHALE-99 (was: STR-2559) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] small patch for the buildfiles > -- > > Key: SHALE-99 > URL: http://issues.apache.org/struts/browse/SHALE-99 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: patch.diff, patch.diff > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-106) [Shale] taglib source code typos
[ http://issues.apache.org/struts/browse/SHALE-106?page=all ] Craig McClanahan moved STR-2497 to SHALE-106: - Project: Shale (was: Struts Action 1) Key: SHALE-106 (was: STR-2497) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [Shale] taglib source code typos > > > Key: SHALE-106 > URL: http://issues.apache.org/struts/browse/SHALE-106 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Bill Young > > I was having some exceptions from shale when trying to use minlength commons > validator from the shale taglib. I traced back the issue to the cause: > src/java/org/apache/shale/taglib/CommonsValidatorTag.java > line 223: typo: max is set to min > reads: validator.setMaxlength(tagUtils.evalInteger(minlength)); > should be: validator.setMaxlength(tagUtils.evalInteger(maxlength)); > While looking I also noticed this as well: > src/conf/taglib.tld > line 67: typo > reads: "trie" > should be: "true" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-105) [shale] Clay doesn't process transient components correctly.
[ http://issues.apache.org/struts/browse/SHALE-105?page=all ] Craig McClanahan moved STR-2491 to SHALE-105: - Project: Shale (was: Struts Action 1) Key: SHALE-105 (was: STR-2491) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] Clay doesn't process transient components correctly. > > > Key: SHALE-105 > URL: http://issues.apache.org/struts/browse/SHALE-105 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: Patch.diff, patch.diff > > Since the tree is processed only once, all transient components are missing > if the dialog is redisplayed. > The only solution without forbidding transient components is to traverse the > tree and recreate missing components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-82) [Shale] Strange behaviour when Clay and JSF tags are mixed on the same page.
[ http://issues.apache.org/struts/browse/SHALE-82?page=all ] Craig McClanahan moved STR-2454 to SHALE-82: Project: Shale (was: Struts Action 1) Key: SHALE-82 (was: STR-2454) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Strange behaviour when Clay and JSF tags are mixed on the same page. > > > Key: SHALE-82 > URL: http://issues.apache.org/struts/browse/SHALE-82 > Project: Shale > Type: Bug > Environment: Operating System: Windows 2000 > Platform: PC > Reporter: Manfred Klug > Attachments: patch.txt > > Each component in the tree needs an unique ID. To support this UIViewRoot has > a > function to create unique IDs (createUniqueId), which is also used by Clay. > When a page is reshown, the components uses the ID to determine whether a > component already exists, or one should be created. It is very important that > createUniqueId creates every time the same sequence of IDs. > And this is the point where the problem lies. > Clay doesn't reprocess the tree, doesn't call createUniqueId, and the sequence > of IDs is damaged. > The easy solution is as follows: > After the Clay-Tag has finished, store the next output of createUniqueId > and when the page is reshown, call createUniqueId an appropriate number of > times. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-111) [shale] clay enhancement - reusable clay components
[ http://issues.apache.org/struts/browse/SHALE-111?page=all ] Craig McClanahan moved STR-2756 to SHALE-111: - Project: Shale (was: Struts Action 1) Key: SHALE-111 (was: STR-2756) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] clay enhancement - reusable clay components > --- > > Key: SHALE-111 > URL: http://issues.apache.org/struts/browse/SHALE-111 > Project: Shale > Type: Improvement > Environment: Operating System: All > Platform: Other > Reporter: Ryan Wynn > Priority: Minor > Attachments: collage-web-dependencies.gif, depends.gif, > shale-collage-skin.jar, shale-collage-skin.zip, shale-collage-skin.zip, > shale-collage-web.jar, shale-collage-web.war, shale-collage-web.war, > shale-collage.jar, shale-collage.zip, shale-collage.zip > > I have developed some clay add-ons that I thought would be useful to share > with the community. The are packaged the form of two projects. One called > collage and one called collage-skin. Collage is basically a set of clay > component definitions with corresponding java helper classes. Collage-Skin > is > an add on skin for these components. The idea is the Collage-Skin would be > the default for examples, but one could create their own version if they > chose > to. Collage-Skin contains css, javascript, and images for the collage > components. Attached you will find collage, collage-skin, and collage-web (a > sample web application that uses collage). > This initial version of collage offers a table, tree, tree-table, some > validation, and a component that manages dependant selectOne widgets. These > are all showcased in the collage-web app which has been tested with Tomcat > 5.0. > Currently collage requires myfaces + tomahawk. In the future it might be > nice > to offer a version that is not dependant on these libraries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-104) [shale] loadBundle component for clay HTML templates
[ http://issues.apache.org/struts/browse/SHALE-104?page=all ] Craig McClanahan moved STR-2530 to SHALE-104: - Project: Shale (was: Struts Action 1) Key: SHALE-104 (was: STR-2530) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] loadBundle component for clay HTML templates > > > Key: SHALE-104 > URL: http://issues.apache.org/struts/browse/SHALE-104 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: component.diff, translation.diff > > Since the standard loadBundle is only a JSP-tag, it can't be used with HTML > templates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-114) French translation for the usecases webapp
[ http://issues.apache.org/struts/browse/SHALE-114?page=all ]
Craig McClanahan moved STR-2657 to SHALE-114:
-
Project: Shale (was: Struts Action 1)
Key: SHALE-114 (was: STR-2657)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> French translation for the usecases webapp
> --
>
> Key: SHALE-114
> URL: http://issues.apache.org/struts/browse/SHALE-114
> Project: Shale
> Type: Improvement
> Environment: Operating System: All
> Platform: All
> Reporter: Alexandre Poitras
> Priority: Minor
> Attachments: Bundle_fr.properties
>
> # Resource Strings for Shale Framework Use Cases Example
> #
> # Copyright 2004-2005 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.
> #
> # $Id$
> # Supported Category Labels
> category.0=Toutes
> category.1=Java
> category.2=Musique
> # Ajax Code Completion Example
> ajax.completion.title=Exemple de Complétion de Code Ajax
> ajax.completion.prompt=Entrez le nom d'un état des États-Unis :
> ajax.completion.finish=Terminer
> ajax.completion.submit=Soumettre
> # JNDI Test Labels
> jndi.test.title=Titre du Test JNDI
> jndi.test.expected=Attendu:
> jndi.test.actual=Réel:
> jndi.test.finish=Terminer
> # Miscellaneous Labels
> label.cancel=Annuler
> label.create=Créer un Nouveau Profil Utilisateur
> label.finish=Terminer
> label.first=Premier
> label.go=Aller
> label.last=Dernier
> label.logon=Se déconnecter
> label.next=Suivant
> label.previous=Précédent
> label.select=Sélectionner
> # Supported Locale Labels
> locale.en=Anglais
> locale.fr=Français
> locale.de=Allemand
> locale.es=Espagnol
> # Logon Dialog Labels and Messages
> logon.create=Créer un nouveau profil utilisateur
> logon.mismatch=Le nom d'utilisateur ou le mot de passe spécifiés sont
> invalides,
> svp essayer de nouveau
> logon.title=Se connecter à l'Application Exemple Use Cases
> logon.title.1=Profil Utilisateur (Page 1 de 3)
> logon.title.2=Profil Utilisateur (Page 2 de 3)
> logon.title.3=Profil Utilisateur (Page 3 de 3)
> logon.unconfirmed=Le nom d'utilisateur que vous avez spécifié n'a pas encore
> été
> confirmé. Pour le confirmer, \
> svp répondez au courriel qui a été envoyé à l'adresse de courriel que vous
> avez
> spécifié.
> # Edit Profile Labels and Messages
> profile.confirm=Le nom d'utilisateur que vous avez spécifié n'a pas encore été
> confirmé. Pour le confirmer, \
> svp répondez au courriel qui a été envoyé à l'adresse de courriel que vous
> avez
> spécifié.
> profile.duplicate=Ce nom d'utilisateur est déjà utilisé, svp essayez de
> nouveau.
> profile.incorrect=Le nom d'utilisateur ou le mot de passe spécifiés sont
> invalides, svp essayer de nouveau
> profile.mismatch=Les valeurs de mot de passes ne correspondent pas, svp
> essayer
> de nouveau
> profile.password=Le mot de passe est requis lors de la création d'un profil
> profile.title=Se connecter à l'Application Exemple Use Cases
> profile.title.1=Profil Utilisateur (Page 1 de 3)
> profile.title.2=Profil Utilisateur (Page 2 de 3)
> profile.title.3=Profil Utilisateur(Page 3 de 3)
> logon.unconfirmed=Le nom d'utilisateur que vous avez spécifié n'a pas encore
> été
> confirmé. Pour le confirmer, \
> svp répondez au courriel qui a été envoyé à l'adresse de courriel que vous
> avez
> spécifié.
> profile.username=Le nom d'utilisateur est requis lors de la création d'un
> profil.
> # Miscellaneous Prompts
> prompt.categories=Catégories de messages:
> prompt.emailAddress=Addresse de courriel:
> prompt.fullName=Nom complet:
> prompt.locale=Locale:
> prompt.password=Mot de passe:
> prompt.password2=Mot de passe (encore):
> prompt.remember=Se souvenir de moi
> prompt.username=Nom d'utilisateur:
> prompt.creditCardNumber=Numéro de Carte de Crédit
> prompt.expirationDate=Date d'Expiration
> # Locale Selection Labels and Messages
> select.mismatch=Vous avez sélectionné une locale non-supportée {0}, alors
> aucun
> changement n'a été commis.
> select.missing=Vous devez spécifier une Locale valide
> select.prerender=Préspécification de la Locale à la valeur {0} dans
> prerender()
> select.prompt=Sélectionnez le langage désiré:
> select.selected=L'utilisateur a sélectionné la Locale {0}
> select.title=Sélectionner la Locale
> # Subview Prompts
> subview.actual=Actuel:
> subview.conti
[jira] Moved: (SHALE-103) [shale] Clay doesn't preserve the component hierarchy in HTML templates
[ http://issues.apache.org/struts/browse/SHALE-103?page=all ] Craig McClanahan moved STR-2526 to SHALE-103: - Project: Shale (was: Struts Action 1) Key: SHALE-103 (was: STR-2526) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Clay doesn't preserve the component hierarchy in HTML templates > --- > > Key: SHALE-103 > URL: http://issues.apache.org/struts/browse/SHALE-103 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: MorphBuilder.patch > > The following snippet > > > > Some Text > > > is processed as follows > > > > Some Text > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-113) [shale] Create "Dialog Aware" button panel component
[ http://issues.apache.org/struts/browse/SHALE-113?page=all ] Craig McClanahan moved STR-2786 to SHALE-113: - Project: Shale (was: Struts Action 1) Key: SHALE-113 (was: STR-2786) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] Create "Dialog Aware" button panel component > > > Key: SHALE-113 > URL: http://issues.apache.org/struts/browse/SHALE-113 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Ed Burns > Priority: Minor > > There really should be a dialog aware button panel component that > automatically > generates next and previous buttons, greying things out as appropriate. > The JSF CharacterCombat demo has some ideas on this. > https://javaserverfaces-sources.dev.java.net/source/browse/javaserverfaces-sources/jsf-demo/characterCombat/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-112) [shale] new clay use case
[ http://issues.apache.org/struts/browse/SHALE-112?page=all ] Craig McClanahan moved STR-2504 to SHALE-112: - Project: Shale (was: Struts Action 1) Key: SHALE-112 (was: STR-2504) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] new clay use case > - > > Key: SHALE-112 > URL: http://issues.apache.org/struts/browse/SHALE-112 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Priority: Minor > Attachments: use-cases.patch, use-cases.zip > > The following patches contain a new use-case for the clay plugin. The use > case features the runtime and xml composition techniques. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-110) [shale] Name and location of validation rules file(s) should be configurable
[ http://issues.apache.org/struts/browse/SHALE-110?page=all ] Craig McClanahan moved STR-2707 to SHALE-110: - Project: Shale (was: Struts Action 1) Key: SHALE-110 (was: STR-2707) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Name and location of validation rules file(s) should be configurable > > > Key: SHALE-110 > URL: http://issues.apache.org/struts/browse/SHALE-110 > Project: Shale > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Wendy Smoak > Priority: Minor > > The oas.validator.CommonsValidator class loads rules and messages from > locations > hard-coded in the class. (Currently /WEB-INF/validator-rules.xml (but see > Bug# > 38042), and /org/apache/shale/validator/messages.properties.) > These files can be overridden by placing modified versions under > WEB-INF/classes, and depending on the order in which the Servlet container is > required to load them (WEB-INF/classes before WEB-INF/lib). > We should allow users to configure the name and location of these files, for > example: > web.xml: > > >validator-config-files > >/org/apache/shale/validator/validator-rules.xml >/WEB-INF/validation.xml > > > > >validator-bundle-name >org.apache.shale.validator.messages > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-90) [shale][core] Testcase ImplClassesTestCase fails.
[ http://issues.apache.org/struts/browse/SHALE-90?page=all ] Craig McClanahan moved STR-2643 to SHALE-90: Project: Shale (was: Struts Action 1) Key: SHALE-90 (was: STR-2643) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale][core] Testcase ImplClassesTestCase fails. > - > > Key: SHALE-90 > URL: http://issues.apache.org/struts/browse/SHALE-90 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: core_testPristine_failure.patch > > [junit] Testsuite: org.apache.shale.dialog.impl.ImplClassesTestCase > [junit] Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 1,272 sec > [junit] Testcase: testExplicitTransitions took 0,991 sec > [junit] Testcase: testImplicitTransitions took 0,121 sec > [junit] Testcase: testPristine took 0,15 sec > [junit] FAILED > [junit] expected:<5> but was:<7> > [junit] junit.framework.AssertionFailedError: expected:<5> but was:<7> > [junit] at > org.apache.shale.dialog.impl.ImplClassesTestCase.testPristine(ImplClassesTestCase.java:248) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-87) [shale] AbstractFacesBean message methods don't use the UIComponent parameter
[ http://issues.apache.org/struts/browse/SHALE-87?page=all ]
Craig McClanahan moved STR-2591 to SHALE-87:
Project: Shale (was: Struts Action 1)
Key: SHALE-87 (was: STR-2591)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [shale] AbstractFacesBean message methods don't use the UIComponent parameter
> -
>
> Key: SHALE-87
> URL: http://issues.apache.org/struts/browse/SHALE-87
> Project: Shale
> Type: Bug
> Environment: Operating System: other
> Platform: Other
> Reporter: Ronald Holshausen
> Priority: Minor
>
> I've noticed that the AbstractFacesBean have a number of message methods
> (info,
> error, warn, fatal) that take a UIComponent parameter, but they don't use it.
> Class: org.apache.shale.view.AbstractFacesBean
> Lines: 223-347
> The current implementation is (for the info method):
> protected void info(UIComponent component, String summary) {
> getFacesContext().addMessage(null,
> new FacesMessage(FacesMessage.SEVERITY_INFO, summary, null));
> }
> and I'm assuming it should be something like:
> protected void info(UIComponent component, String summary) {
> FacesContext facesContext = getFacesContext();
> facesContext.addMessage(component.getClientId(facesContext),
> new FacesMessage(FacesMessage.SEVERITY_INFO, summary, null));
> }
> This pattern is the same for warn, error and fatal methods that take a
> UIComponent parameter.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-77) [shale] application freezes if ids for clay components are duplicated
[ http://issues.apache.org/struts/browse/SHALE-77?page=all ] Craig McClanahan moved STR-2522 to SHALE-77: Project: Shale (was: Struts Action 1) Key: SHALE-77 (was: STR-2522) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] application freezes if ids for clay components are duplicated > - > > Key: SHALE-77 > URL: http://issues.apache.org/struts/browse/SHALE-77 > Project: Shale > Type: Bug > Environment: Operating System: Windows Server 2003 > Platform: Other > Reporter: Sergey Smirnov > Attachments: clay.patch, dup.patch > > I had added two clay components to my test example which had the same id > accidentally. The application froze instead of reporting about duplicate id. > The problem is reproduced on my side if I add: > > > just after on the rolodex.jsp of shale-usecase app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-89) [Shale] Ant build: htmlunit issues
[ http://issues.apache.org/struts/browse/SHALE-89?page=all ] Craig McClanahan moved STR-2807 to SHALE-89: Project: Shale (was: Struts Action 1) Key: SHALE-89 (was: STR-2807) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Ant build: htmlunit issues > -- > > Key: SHALE-89 > URL: http://issues.apache.org/struts/browse/SHALE-89 > Project: Shale > Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Niall Pemberton > Priority: Minor > > I found a couple of issues with the ant build running "ant dist" for the > whole > of shale: > 1) If "html.unit" isn't set the build fails. > 2) There are a couple of compile errors with HtmlUnit 1.8 (fine with 1.6) > Either the build should be changed to download htmlunit and Commons > httpclient > automatically using the download-dependencies target or at least add an entry > in build.properties.sample for htmlunit and modify the test build.xml so that > it doesn't fail if htmlunit.home isn't specified. > I guess the disadvantage of downloading automatically is that different > versions of htmlunit may depend on different versions of commons httpclient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-79) [shale] Validator deprecations
[ http://issues.apache.org/struts/browse/SHALE-79?page=all ] Craig McClanahan moved STR-2626 to SHALE-79: Project: Shale (was: Struts Action 1) Key: SHALE-79 (was: STR-2626) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Validator deprecations > -- > > Key: SHALE-79 > URL: http://issues.apache.org/struts/browse/SHALE-79 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Attachments: shale_validator_deprecations.patch > > Its best to remove validator deprecations in current code since a Commons > Validator 1.2.0 may not be too far away and this will allow Shale to pick it > up once its available. > Removed deprecations: > 1) org.apache.commons.validator.ValidatorResourcesInitializer > 2) org.apache.commons.validator.ValidatorAction#getMethodParamsList() > Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-83) [shale] "categories" selectManyCheckBox in usecases fails to validate
[ http://issues.apache.org/struts/browse/SHALE-83?page=all ] Craig McClanahan moved STR-2622 to SHALE-83: Project: Shale (was: Struts Action 1) Key: SHALE-83 (was: STR-2622) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] "categories" selectManyCheckBox in usecases fails to validate > - > > Key: SHALE-83 > URL: http://issues.apache.org/struts/browse/SHALE-83 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > > For reproducing, deploy the Shale 11/4 nightlies usecases war: > 1) Navigate to view corresponding to profile/profile3.jsp in Edit Profile > dialog. > 2) Optionally make one or more checkbox selections. Try to navigate away > while > staying in the dialog (i.e. other than cancel -- previous or finish). > Validation for "categories" selectManyCheckBox fails with > javax.faces.component.UISelectMany.INVALID with no obvious clue. > Sorry, I haven't investigated beyond that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-81) [shale] Patch to remove the deprecated BaseViewController.
[ http://issues.apache.org/struts/browse/SHALE-81?page=all ] Craig McClanahan moved STR-2556 to SHALE-81: Project: Shale (was: Struts Action 1) Key: SHALE-81 (was: STR-2556) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Patch to remove the deprecated BaseViewController. > -- > > Key: SHALE-81 > URL: http://issues.apache.org/struts/browse/SHALE-81 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: patch.diff > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-95) resource properties
[ http://issues.apache.org/struts/browse/SHALE-95?page=all ] Craig McClanahan moved STR-2705 to SHALE-95: Project: Shale (was: Struts Action 1) Key: SHALE-95 (was: STR-2705) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > resource properties > --- > > Key: SHALE-95 > URL: http://issues.apache.org/struts/browse/SHALE-95 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Matthias Wessendorf > Attachments: patch.txt > > attached german translation of shale's properties > also removed a double entry from *default* properties file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-93) [shale] Clay View-Handler doesn't work correctly with client side state saving.
[ http://issues.apache.org/struts/browse/SHALE-93?page=all ] Craig McClanahan moved STR-2519 to SHALE-93: Project: Shale (was: Struts Action 1) Key: SHALE-93 (was: STR-2519) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Clay View-Handler doesn't work correctly with client side state > saving. > --- > > Key: SHALE-93 > URL: http://issues.apache.org/struts/browse/SHALE-93 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: ClayViewHandler.patch > > The problem is that the RI and myFaces only write markers, and the View-Tag > replaces these markers with the real data. > Additionally, myFaces has a second marker to write the state as URL-Parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-92) [Shale] project xml dependencies
[ http://issues.apache.org/struts/browse/SHALE-92?page=all ] Craig McClanahan moved STR-2328 to SHALE-92: Project: Shale (was: Struts Action 1) Key: SHALE-92 (was: STR-2328) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] project xml dependencies > > > Key: SHALE-92 > URL: http://issues.apache.org/struts/browse/SHALE-92 > Project: Shale > Type: Bug > Environment: Operating System: Windows XP > Platform: PC > Reporter: Hal Deadman > Attachments: maven.txt > > Shale is missing some maven library dependencies, changed servlet api > dependency to match version in maven repo on ibiblio. Adds jsp-api and > commons- > chain. > Index: C:/eclipse31m4/eclipse/workspace/struts-shale/project.xml > === > --- C:/eclipse31m4/eclipse/workspace/struts-shale/project.xml (revision > 124904) > +++ C:/eclipse31m4/eclipse/workspace/struts-shale/project.xml (working copy) > @@ -136,12 +136,22 @@ > > tomcat > servlet-api > - 5.0.28 > + 5.0.18 > http://jakarta.apache.org/tomcat/ > > false > > > + > + > +tomcat > + jsp-api > + 5.0.18 > + http://jakarta.apache.org/tomcat/ > + > + false > + > + > >
[jira] Moved: (SHALE-94) [shale] Static members accessed in non-static way
[ http://issues.apache.org/struts/browse/SHALE-94?page=all ] Craig McClanahan moved STR-2623 to SHALE-94: Project: Shale (was: Struts Action 1) Key: SHALE-94 (was: STR-2623) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Static members accessed in non-static way > - > > Key: SHALE-94 > URL: http://issues.apache.org/struts/browse/SHALE-94 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Priority: Minor > Attachments: shale_static_access.patch > > Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-86) Add Java Doc to may source files and add more Tapestry like support
[ http://issues.apache.org/struts/browse/SHALE-86?page=all ] Craig McClanahan moved STR-2429 to SHALE-86: Project: Shale (was: Struts Action 1) Key: SHALE-86 (was: STR-2429) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Add Java Doc to may source files and add more Tapestry like support > > > Key: SHALE-86 > URL: http://issues.apache.org/struts/browse/SHALE-86 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Gary VanMatre > Attachments: delta-source.zip, diff.log, diff.txt, fournew.jar > > Many of the source files didn't have javadoc. The html and > tags didn't have tapestry like binding. > An example follows: > HTML Fragment: > > >Notice > > > >data for mockup > > > > XML Config Fragment: > > componentType="javax.faces.HtmlInputTextarea"/> > > >value="http://www.globalsecurity.org/wmd/systems/ebs.htm"/> > > > > > > > > > added java doc > M component/chain/PropertyValueCommand.java > M component/chain/PropertyActionCommand.java > M component/chain/PropertyActionListenerCommand.java > M component/chain/PropertyValidatorCommand.java > M component/chain/PropertyValueChangeListenerCommand.java > changed getElementId() to getJsfid() and added java doc > M parser/Node.java > M parser/builder/SelectManyMenuBuilder.java > M parser/builder/chain/SpanBuilderRule.java > M parser/builder/chain/FormBuilderRule.java > M parser/builder/chain/BuilderRuleContext.java > M parser/builder/chain/DefaultBuilderRule.java > M parser/builder/chain/OptionBuilderRule.java > M parser/builder/chain/InputBuilderRule.java > M parser/builder/chain/LabelBuilderRule.java > M parser/builder/chain/SelectBuilderRule.java > M parser/builder/SelectItemBuilder.java > M parser/builder/OutputLabelBuilder.java > M parser/builder/SelectOneRadioBuilder.java > M parser/builder/FormBuilder.java > M parser/builder/InputTextBuilder.java > M parser/builder/SelectOneMenuBuilder.java > M parser/builder/BuilderFactory.java > M parser/builder/VerbatimBuilder.java > M parser/builder/CommandButtonBuilder.java > M parser/builder/Builder.java > M parser/builder/SelectItemsBuilder.java > M parser/builder/MorphBuilder.java > M parser/builder/SelectBooleanCheckboxBuilder.java > registered two new builder rules > M parser/builder/chain/shale-builder-config.xml > Added two new builder and associated rules > A parser/builder/OutputLinkBuilder.java > A parser/builder/InputTextareaBuilder.java > A parser/builder/chain/AnchorBuilderRule.java > A parser/builder/chain/TextareaBuilderRule.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-85) [Shale] Problems with CommonsValidator on the server side.
[ http://issues.apache.org/struts/browse/SHALE-85?page=all ] Craig McClanahan moved STR-2461 to SHALE-85: Project: Shale (was: Struts Action 1) Key: SHALE-85 (was: STR-2461) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Problems with CommonsValidator on the server side. > -- > > Key: SHALE-85 > URL: http://issues.apache.org/struts/browse/SHALE-85 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: Patch.diff, patch.diff, patch.diff > > At the moment I see two problematic areas. > - The 'required' validation doesn't work on the server. > - All validations which need a String as value may translate the converted > value back to a String. This has the following disadvantages: > -- Validation depends on the toString method and not on the user input. > -- It's impossible to control a sloppy converter. (Enter an invalid value in > a field with a 'numberConverter', and you know what I mean). > In addition, I think the displayed value in the error message should be the > submitted and not the converted value. > A possible solution could look as follows: > - If the 'required' validation is configured for server side validation, an > exception with a helpful error message is thrown. > - Instead of converting the value back to a String, use directly the submitted > value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-80) [shale] Clay outputLink definition missing target attribute
[ http://issues.apache.org/struts/browse/SHALE-80?page=all ] Craig McClanahan moved STR-2835 to SHALE-80: Project: Shale (was: Struts Action 1) Key: SHALE-80 (was: STR-2835) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Clay outputLink definition missing target attribute > --- > > Key: SHALE-80 > URL: http://issues.apache.org/struts/browse/SHALE-80 > Project: Shale > Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Richarad Wallace > > Currently the outputLink definition in clay just extends the baseOutput > component. An attribute needs to be added so that the target attribute can > be used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-91) [struts-faces] Example application doesn't deploy
[ http://issues.apache.org/struts/browse/SHALE-91?page=all ] Craig McClanahan moved STR-2792 to SHALE-91: Project: Shale (was: Struts Action 1) Key: SHALE-91 (was: STR-2792) Component: (was: Faces) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [struts-faces] Example application doesn't deploy > - > > Key: SHALE-91 > URL: http://issues.apache.org/struts/browse/SHALE-91 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Roland > Priority: Critical > > Hello, > I'm running Apache Tomcat/4.1.31 > And java version "1.4.2_06" on Linux. > I'm trying to deploy the example applications which come with > struts-faces-20060313 nightly but I get the following errors: > 2006-03-13 14:45:44 WebappLoader[/struts-faces-example2]: Deploy JAR > /WEB-INF/lib/struts-faces.jar to > /var/roland/CATALINA_BASE/webapps/struts-faces-example2/WEB-INF/lib/struts-faces.jar > 2006-03-13 14:45:44 WebappLoader[/struts-faces-example2]: Deploy JAR > /WEB-INF/lib/struts.jar to > /var/roland/CATALINA_BASE/webapps/struts-faces-example2/WEB-INF/lib/struts.jar > 2006-03-13 14:45:44 StandardManager[/struts-faces-example2]: Seeding random > number generator class java.security.SecureRandom > 2006-03-13 14:45:44 StandardManager[/struts-faces-example2]: Seeding of random > number generator has been completed > 2006-03-13 14:45:46 StandardContext[/struts-faces-example2]: Exception sending > context initialized event to listener instance of class > com.sun.faces.config.ConfigureListener > java.lang.UnsupportedClassVersionError: > org/apache/struts/faces/application/ActionListenerImpl (Unsupported > major.minor > version 49.0) > at java.lang.ClassLoader.defineClass0(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:539) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) > at > org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1649) > at > org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:931) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1373) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1252) > at com.sun.faces.util.Util.loadClass(Util.java:403) > at com.sun.faces.util.Util.createInstance(Util.java:1150) > at > com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:460) > at > com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:402) > at > com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:332) > at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3212) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:3554) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:774) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:760) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:548) > at > org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:260) > at org.apache.catalina.core.StandardHost.install(StandardHost.java:741) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:445) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:353) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:671) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1149) > at org.apache.catalina.core.StandardHost.start(StandardHost.java:707) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1141) > at > org.apache.catalina.core.StandardEngine.start(StandardEngine.java:316) > at > org.apache.catalina.core.StandardService.start(StandardService.java:450) > at > org.apache.catalina.core.StandardServer.start(StandardServer.java:2143) > at org.apache.catalina.startup.Catalina.start(Catalina.java:463) > at org.apache.catalina.startup.Catalina.execute(Catalina.java:350) > at org.apache.catalina.startup.Catalina.process(Catalina.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > a
[jira] Moved: (SHALE-71) [Shale] Clay clayForEach tag renders content twice
[ http://issues.apache.org/struts/browse/SHALE-71?page=all ] Craig McClanahan moved STR-2773 to SHALE-71: Project: Shale (was: Struts Action 1) Key: SHALE-71 (was: STR-2773) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay clayForEach tag renders content twice > -- > > Key: SHALE-71 > URL: http://issues.apache.org/struts/browse/SHALE-71 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Hermod Opstvedt > > In the nightlys the Clay clayForEach tag renders the content twice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-76) Kickstart FAQ Patch for Shale
[ http://issues.apache.org/struts/browse/SHALE-76?page=all ] Craig McClanahan moved STR-2356 to SHALE-76: Project: Shale (was: Struts Action 1) Key: SHALE-76 (was: STR-2356) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Kickstart FAQ Patch for Shale > - > > Key: SHALE-76 > URL: http://issues.apache.org/struts/browse/SHALE-76 > Project: Shale > Type: Bug > Environment: Operating System: Windows XP > Platform: PC > Reporter: Ted Husted > Attachments: struts-151664.patch > > I'm having trouble committing from a new workstation, for some reason, and the > usual station is in shop. Here's a patch that adds the Shale q&a to the > Kickstart FAQ, and a reference to commons-collections that I had to add to > build.xml before Core would build for me. Could someone apply this for me > while > I sort out what's up with my access? > -Ted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-65) [Shale] client side commons validation not working inside a dataList
[ http://issues.apache.org/struts/browse/SHALE-65?page=all ]
Craig McClanahan moved STR-2817 to SHALE-65:
Project: Shale (was: Struts Action 1)
Key: SHALE-65 (was: STR-2817)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [Shale] client side commons validation not working inside a dataList
>
>
> Key: SHALE-65
> URL: http://issues.apache.org/struts/browse/SHALE-65
> Project: Shale
> Type: Bug
> Environment: Operating System: All
> Platform: All
> Reporter: Paul Devine
> Attachments: shale_debug.war
>
> Overview:
> I was using Shale nightly build 20060328. See
> http://www.mail-archive.com/user%40struts.apache.org/msg44124.html for
> pertinent
> mailing list discussion. For inputs inside a dataList a row index is included
> in
> the clientId to guarantee uniqueness on the html input id's. For example
> "myForm:myDataList_0:someRequiredField" for the first row,
> "myForm:myDataList_1:someRequiredField" for the second, and so on. But in
> the rendering of the javascript by the struts validatorScript tag, the
> clientId of the input components lose their row index.
> To reproduce:
> Deploy the jsp file whose source is included at the end of this description
> into
> a minimal myfaces web-app. Drop into WEB-INF/lib the shale-core dependency
> files
> and a myfaces-1.1.1 "all" jar.
> Start the web-app and open http://localhost:8080/shale_debug/index.jsf. Do a
> view source on the html and you will see two fields with their id's
> "someForm:someDataList_0:someRequiredField" and
> "someForm:someDataList_0:someRequiredField". But in the validation javascript
> function required() you'll see only one input
> "someForm:someDataList:someRequiredField". If you submit the form without
> filling out the required fields you will notice that a javascript error occurs
> causing client side validation to be skipped. The server-side validation
> works ok.
> The full list of jars you need in WEB-INF/lib is :
> commons-beanutils.jar, commons-chain.jar,commons-codec-1.3.jar,
> commons-digester.jar, commons-fileupload.jar, commons-logging.jar,
> commons-validator.jar, shale-core.jar, myfaces-all-1.1.1.jar
>
> ==
> The source for the index.jsp is as follows:
> ==
> <%@ page language="java"
> import="java.util.*,org.apache.shale.dialog.impl.DialogImpl"%>
> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
> <%@ taglib uri="http://myfaces.apache.org/extensions"; prefix="t"%>
> <%@ taglib uri="http://struts.apache.org/shale/core"; prefix="s" %>
> <%
> /* Put a couple of Shale DialogImpl objects into the session (we just need an
> object with a getter and a setter
> * and this class is readily accessible)
> */
> List inputObjects = new ArrayList();
> inputObjects.add(new DialogImpl());
> inputObjects.add(new DialogImpl());
> session.setAttribute("someInputObjects",inputObjects);
> %>
>
> <%--
> A form with a dataList of inputs. The client side id's of the components will
> be
> someForm:someDataList_0:someRequiredField and
> someForm:someDataList_1:someRequiredField
> --%>
>
>rowIndexVar="index">
>
> required="true">
>client="true"/>
> errorClass="errorMessage"/>
>
> <%--
> The dataList is now closed. Before we close out the form, write out the
> validator javascript. But
> this results in a mismatch on the client side id's in the required function.
> Note the uniqueness
> indexes _0 and _1 are missing. Because we are outside the
> dataList there is no "row index" anymore (and for some reason the
> HtmlInputText
> components `calculate`
> their clientId's again when asked for getClientId from Shale's ValidatorScript
> findCommonsValidators method
> Here's what the validatorScript comes up with:-
> function required() {
> this[0] = new Array("someForm:someDataList:someRequiredField", "Name is
> required.", new Function("x", "return {}[x];"));
> }
> --%>
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-58) Clay TH Bug
[ http://issues.apache.org/struts/browse/SHALE-58?page=all ] Craig McClanahan moved STR-2714 to SHALE-58: Project: Shale (was: Struts Action 1) Key: SHALE-58 (was: STR-2714) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > Clay TH Bug > --- > > Key: SHALE-58 > URL: http://issues.apache.org/struts/browse/SHALE-58 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Hermod Opstvedt > > Hi > I have discovered a possible bug in Clay with respect to table th tags: > This can be verified as follows: > Put the following on a page > > > > > > > > This will give an error: > javax.servlet.ServletException: Unmatched ending non-optional token: Node > token > range (43 - 48) on line# 5 begining offset 40. > > javax.faces.webapp.FacesServlet.service(FacesServlet.java:121) > > org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:123) > > org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:285) > while this: > > > > > > > > works just fine > Hermod -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-68) ValidatorCommandRenderer breaks MyFaces dummy form.
[ http://issues.apache.org/struts/browse/SHALE-68?page=all ] Craig McClanahan moved STR-2833 to SHALE-68: Project: Shale (was: Struts Action 1) Key: SHALE-68 (was: STR-2833) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > ValidatorCommandRenderer breaks MyFaces dummy form. > --- > > Key: SHALE-68 > URL: http://issues.apache.org/struts/browse/SHALE-68 > Project: Shale > Type: Bug > Environment: Operating System: Windows XP > Platform: PC > Reporter: Simon Matic Langford > > I have a webapp using shale over myfaces, and the front page is a menu, using > jscookmenu. On an older nightly build all was fine, but when I took build > 20060408 of shale core, the menu links stopped working. I traced this back to > the ValidatorCommandRenderer creating a new ResponseWriter: > ResponseWriter buffResponsewriter = context.getRenderKit() > .createResponseWriter(writer, null, > hijackedWriter.getCharacterEncoding()); > This means that when HtmlJSCookMenuRenderer calls setWriteDummyForm(true) on > the > writer, the value is not propagated to the main writer for the view and so the > dummy form is no longer output. The source for the page is: > <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> > <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> > <%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%> > > > > > > > > > > > >action="newProject"/> > > > > >action="dataAssignment"/> > > > >action="helpGettingStarted"/> > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-78) [shale] Two web site improvements
[ http://issues.apache.org/struts/browse/SHALE-78?page=all ] Craig McClanahan moved STR-2734 to SHALE-78: Project: Shale (was: Struts Action 1) Key: SHALE-78 (was: STR-2734) Component: (was: Web Site) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Two web site improvements > - > > Key: SHALE-78 > URL: http://issues.apache.org/struts/browse/SHALE-78 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Dennis C. Byrne > Attachments: xdocs.txt > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-70) [Shale] Clay PropUtil.decodeSimpleProperty: Converting a string to double fails if the locale is not english.
[ http://issues.apache.org/struts/browse/SHALE-70?page=all ] Craig McClanahan moved STR-2459 to SHALE-70: Project: Shale (was: Struts Action 1) Key: SHALE-70 (was: STR-2459) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Clay PropUtil.decodeSimpleProperty: Converting a string to double > fails if the locale is not english. > - > > Key: SHALE-70 > URL: http://issues.apache.org/struts/browse/SHALE-70 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > > Seems that DecimalFormat uses always the format symbols of the current > locale. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-84) [shale] NumberConverter missing from clay base definitions
[ http://issues.apache.org/struts/browse/SHALE-84?page=all ] Craig McClanahan moved STR-2754 to SHALE-84: Project: Shale (was: Struts Action 1) Key: SHALE-84 (was: STR-2754) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] NumberConverter missing from clay base definitions > -- > > Key: SHALE-84 > URL: http://issues.apache.org/struts/browse/SHALE-84 > Project: Shale > Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Richarad Wallace > > The NumberConverter is missing from the base definitions in the packaged > /META-INF/clay-config.xml. Here is a definition based on the existing ones > that > works for me. > > > > > > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-75) [Shale] Shale and Clay tags cannot be used on the same page
[ http://issues.apache.org/struts/browse/SHALE-75?page=all ] Craig McClanahan moved STR-2455 to SHALE-75: Project: Shale (was: Struts Action 1) Key: SHALE-75 (was: STR-2455) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [Shale] Shale and Clay tags cannot be used on the same page > --- > > Key: SHALE-75 > URL: http://issues.apache.org/struts/browse/SHALE-75 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > Attachments: patch.txt > > since both taglibs share the same URI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-74) [shale] Position (inner class) should implement Serializable
[ http://issues.apache.org/struts/browse/SHALE-74?page=all ] Craig McClanahan moved STR-2475 to SHALE-74: Project: Shale (was: Struts Action 1) Key: SHALE-74 (was: STR-2475) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Position (inner class) should implement Serializable > > > Key: SHALE-74 > URL: http://issues.apache.org/struts/browse/SHALE-74 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: PC > Reporter: sean schofield > Attachments: shale-35068.patch > > At one point Tomcat complained about not being able to serialize > Status$Position. This class should really implement Serializable otherwise > any > class that implements Status and makes use of Position (such as Status) cannot > be serialized. > Also, this got me thinking about why Position is declared as part of the > Status > interface. Presumably there is a good reason but I can't think of any > advantages to this offhand. In fact its a little bit disconcerting for the > average user (me) who has not ever seen an inner class in an interface > before. > Obviously its permissable but I think we should consider making it its own > class > unless there is a compelling reason to have it this way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-60) [shale] Clay template reloading problem.
[ http://issues.apache.org/struts/browse/SHALE-60?page=all ] Craig McClanahan moved STR-2583 to SHALE-60: Project: Shale (was: Struts Action 1) Key: SHALE-60 (was: STR-2583) Component: (was: Shale) Version: (was: Unknown) Assign To: (was: Struts Developer Mailing List) > [shale] Clay template reloading problem. > > > Key: SHALE-60 > URL: http://issues.apache.org/struts/browse/SHALE-60 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Manfred Klug > > Templates are not reloaded if the XML configuration is changed. This behavior > makes the dynamic load mechanism almost unusable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-69) [shale][clay] Javadoc typos
[ http://issues.apache.org/struts/browse/SHALE-69?page=all ] Craig McClanahan moved STR-2625 to SHALE-69: Project: Shale (was: Struts Action 1) Key: SHALE-69 (was: STR-2625) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale][clay] Javadoc typos > --- > > Key: SHALE-69 > URL: http://issues.apache.org/struts/browse/SHALE-69 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Attachments: clay_javadoc_typos.patch > > Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-73) range validators doesn't check dependecies
[ http://issues.apache.org/struts/browse/SHALE-73?page=all ]
Craig McClanahan moved STR-2710 to SHALE-73:
Project: Shale (was: Struts Action 1)
Key: SHALE-73 (was: STR-2710)
Component: (was: Shale)
Version: (was: Unknown)
Assign To: (was: Struts Developer Mailing List)
> range validators doesn't check dependecies
> --
>
> Key: SHALE-73
> URL: http://issues.apache.org/struts/browse/SHALE-73
> Project: Shale
> Type: Bug
> Environment: Operating System: other
> Platform: All
> Reporter: Luca Conte
>
> I note that the class "public class CommonsValidator implements Validator,
> Serializable" used by tag: max="5"
> arg="Arg1" server="true"
> client="false"/> FAILS if I put a string not stictly numerical like "foo" this
> because the class does not check "validator depends" before validate the value
> whith "intRange".
> I solved by change this row into "public void validate(FacesContext context,
> IComponent component, Object value)" method:
> params[0] = convert(value, paramTypes[0], component);
> with this code (I added the try-catch block):
> try{
> params[0] = convert(value, paramTypes[0], component);
> }catch(Exception e){
> Object errorValue = value;
> if(component instanceof EditableValueHolder)
>errorValue = ((EditableValueHolder)component)
> .getSubmittedValue();
> throw new ValidatorException(new FacesMessage(
> FacesMessage.SEVERITY_ERROR,
> getErrorMessage(errorValue, context), null));
> }
> As U can note the code inside the catch block is the same as the code used if
> the value submitted fails the validation.
> My solution should be rewroted better.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-59) [shale][usecases] EditProfileState should be Serializable
[ http://issues.apache.org/struts/browse/SHALE-59?page=all ] Craig McClanahan moved STR-2653 to SHALE-59: Project: Shale (was: Struts Action 1) Key: SHALE-59 (was: STR-2653) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale][usecases] EditProfileState should be Serializable > - > > Key: SHALE-59 > URL: http://issues.apache.org/struts/browse/SHALE-59 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Attachments: editprofilestate_serializable.patch > > EditProfileState should be Serializable by virtue of being "dialog data", and > hence, a part of the session attributes. > Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-72) FactoryFinder.releaseFactories() & only one renderkit instance
[ http://issues.apache.org/struts/browse/SHALE-72?page=all ] Craig McClanahan moved STR-2733 to SHALE-72: Project: Shale (was: Struts Action 1) Key: SHALE-72 (was: STR-2733) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > FactoryFinder.releaseFactories() & only one renderkit instance > -- > > Key: SHALE-72 > URL: http://issues.apache.org/struts/browse/SHALE-72 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Dennis C. Byrne > Attachments: AbstractJsfTestCaseTest.java, RenderKitJvmIdentity.java, > patch.txt, test-framework.txt > > http://marc.theaimsgroup.com/?l=struts-user&m=113730809202716&w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-61) [shale] Maintaining dialog synchronization when browser navigation buttons are used
[ http://issues.apache.org/struts/browse/SHALE-61?page=all ] Craig McClanahan moved STR-2652 to SHALE-61: Project: Shale (was: Struts Action 1) Key: SHALE-61 (was: STR-2652) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Maintaining dialog synchronization when browser navigation buttons > are used > --- > > Key: SHALE-61 > URL: http://issues.apache.org/struts/browse/SHALE-61 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > > I thought about making this an enhancement, but based on discussions on the > dev list, it seems there is a fair bit of interest in solving this at the > framework level. > The issue is about maintaining client-server dialog synchronization when > browser's navigation buttons are used while in the midst of a Shale dialog. > More details -- and the proof of concept for one potential approach at > resolving this -- are here: > http://people.apache.org/~rahul/shale/align-dialog/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-64) [shale][docs] Enhance DefaultViewControllerMapper Javadocs to reflect view identifier restrictions
[ http://issues.apache.org/struts/browse/SHALE-64?page=all ] Craig McClanahan moved STR-2651 to SHALE-64: Project: Shale (was: Struts Action 1) Key: SHALE-64 (was: STR-2651) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale][docs] Enhance DefaultViewControllerMapper Javadocs to reflect view > identifier restrictions > -- > > Key: SHALE-64 > URL: http://issues.apache.org/struts/browse/SHALE-64 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Rahul Akolkar > Attachments: dvcm_javadoc.patch > > Background: > http://marc.theaimsgroup.com/?l=struts-dev&m=113201965124157&w=2 > Patch follows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-56) [shale] ${htmlunit.home} breaks build
[ http://issues.apache.org/struts/browse/SHALE-56?page=all ]
Craig McClanahan moved STR-2775 to SHALE-56:
Project: Shale (was: Struts Action 1)
Key: SHALE-56 (was: STR-2775)
Component: (was: Shale)
Version: (was: Nightly Build)
Assign To: (was: Struts Developer Mailing List)
> [shale] ${htmlunit.home} breaks build
> -
>
> Key: SHALE-56
> URL: http://issues.apache.org/struts/browse/SHALE-56
> Project: Shale
> Type: Bug
> Environment: Operating System: other
> Platform: Other
> Reporter: Dennis C. Byrne
> Attachments: htmlunit.txt
>
> Followed the instructions @ http://struts.apache.org/struts-
> shale/building.html , verbatim .
> Received an ant build error w/ 'ant clean release':
> shale\test-framework\build.xml:48: ... shale\test-framework\${htmlunit.home}
> \lib not found.
> Commented out reference to $htmlunit.home in shale\test-framework\build.xml
> Ran 'ant clean release' and all is well.
> Repeated all steps twice with the same results.
> Dennis Byrne
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-66) [shale] org.apache.shale.Constants breaks OOP
[ http://issues.apache.org/struts/browse/SHALE-66?page=all ]
Craig McClanahan moved STR-2293 to SHALE-66:
Project: Shale (was: Struts Action 1)
Key: SHALE-66 (was: STR-2293)
Component: (was: Sandbox)
Version: (was: Unknown)
Assign To: (was: Struts Developer Mailing List)
> [shale] org.apache.shale.Constants breaks OOP
> -
>
> Key: SHALE-66
> URL: http://issues.apache.org/struts/browse/SHALE-66
> Project: Shale
> Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Dakota Jack
> Attachments: Constants.java, Constants.java, ShaleConstants.java,
> ShaleConstants.patch
>
> I would suggest that org.apache.shale.Constants be changed from:
> public interface Constants {
> }
> to:
> public class Constants {
> private Constants() {}
> }
> in order to comply with OOP requirements. The internal use of a constant is
> an
> implementation detail and implementing a constant interface causes this
> implementation detail to leak into the exported API. There are lots of
> reasons
> not to use a constant interface, see Item 17 in Joshua Block's "Effective
> Java".
> Also, we might want to create a map for the constants here as is typically
> done, for example:
> public class Constants {
> private Constants() {}
> public static Map getConstantsMap() {
> Map propMap = null;
> try {
> Field[] allFields = Constants.class.getDeclaredFields();
> int numFields = allFields.length;
> propMap = new HashMap(numFields);
> for(int i = 0; i < numFields; i++) {
> Field f = allFields[i];
> int mods = f.getModifiers();
> if(Modifier.isPublic(mods) &&
>Modifier.isStatic(mods) &&
>Modifier.isFinal(mods)) {
> String name = f.getName();
> Object value = f.get(null);
> propMap.put(name, value);
> }
> }
> } catch(IllegalAccessException iae) {
> // log code
> }
> return Collections.unmodifiableMap(propMap);
> }
> }
> I hope this is an appropriate place for Shale suggestions. I don't want to
> find
> myself in the wrong places again.
> Jack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SHALE-63) [shale] Implement serializability on classes potentially stored in session scope
[ http://issues.apache.org/struts/browse/SHALE-63?page=all ] Craig McClanahan moved STR-2667 to SHALE-63: Project: Shale (was: Struts Action 1) Key: SHALE-63 (was: STR-2667) Component: (was: Shale) Version: (was: Nightly Build) Assign To: (was: Struts Developer Mailing List) > [shale] Implement serializability on classes potentially stored in session > scope > > > Key: SHALE-63 > URL: http://issues.apache.org/struts/browse/SHALE-63 > Project: Shale > Type: Bug > Environment: Operating System: other > Platform: Other > Reporter: Craig McClanahan > > The following Shale implementation classes can potentially be stored in > session > scope (and therefore be required by the J2EE spec to be serializable), but are > not currently serializable: > * org.apache.shale.validator.CommonsValidator > * org.apache.shale.dialog.impl.DialogImpl > Unit tests also need to be added to verify the serializability of these and > other classes that must implement it. > The following classes inherit "implements Serializable" from their parent > class > in Commons Chain, even though they are not and cannot actually implement > this. > That is not a direct problem for Shale usage (these classes are only used to > represent per-request state information), but might still get flagged on > audits > of a Shale based webapp: > * org.apache.shale.faces.ShaleWebContext > * org.apache.shale.remote.RemoteContext -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
