[jira] Commented: (SHALE-295) collect web archives with explicit configured faces-config.xml pointing to them
[ http://issues.apache.org/struts/browse/SHALE-295?page=comments#action_38301 ] Mario Ivankovits commented on SHALE-295: What this patch do: Say you have a web.xml with the following configuration: javax.faces.CONFIG_FILES=/content/app/conf/faces-config.xml,/content/app2/conf/faces-config.xml The first faces-config.xml is located in myapp.jar and the second one is located in myapp2.jar. Both jars do NOT have a META-INF/faces-config.xml due to the use of javax.faces.CONFIG_FILES shale-tiger ignores those jars due to this fact. The patch lookup those jars and add them to the list of webArchives. Just for safety I changed the List to a TreeSet. It is possible that such a jar contains a META-INF/faces-config.xml and also some additional special faces-config.xml pointing to with javax.faces.CONFIG_FILES. To not parse them twice is the reason why I changed it to a Set. > collect web archives with explicit configured faces-config.xml pointing to > them > --- > > Key: SHALE-295 > URL: http://issues.apache.org/struts/browse/SHALE-295 > Project: Shale > Issue Type: Improvement > Components: Tiger >Reporter: Mario Ivankovits > Attachments: explicit_jars.diff > > > The patch will also collect jars in WEB-INF/lib which have a faces-config.xml > pointing to them through the configuration javax.faces.CONFIG_FILES > That way, you no longer need to have a "marker" faces-config.xml in META-INF. > The patch is not heavily tested yet. -- 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
[jira] Updated: (SHALE-220) init() lifecycle method called twice
[ http://issues.apache.org/struts/browse/SHALE-220?page=all ]
Bob Butash updated SHALE-220:
-
I have an issue that is similar to Shale 220
(http://issues.apache.org/struts/browse/SHALE-220). I am using Shale version
1.0.3 and for normal View/ViewController processing the init method is only
being invoked once. However I have a subview that has a ViewController backing
bean associated with it. The sub view's init call back method is being called
twice. Is this a known issue, and is there any way to prevent it.
> init() lifecycle method called twice
>
>
> Key: SHALE-220
> URL: http://issues.apache.org/struts/browse/SHALE-220
> Project: Shale
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Craig McClanahan
> Assigned To: Craig McClanahan
> Fix For: 1.0.3
>
>
> From a user mailing list posting by Viswanath ,
> following up on earlier mailing list conversations:
> ==
> Hi Craig,
> Now that I have subscribed to Shale user group, I am posting this issue again.
> Just to make sure that I am not using older version of Shale libraries, I
> have downloaded shale-framework-20060713.zip and tried, same problem. This is
> what I did, to reproduce the issue in usecases project. ( I am not able to
> post code from my project because of lot of dependencies on EJBs/Database)
> I downloaded the latest usecases zip (07/14/2006). Unzipped the war file into
> a directory, created a project in eclipse, added the java source files,
> built and deployed it into JBOSS and it ran fine. Added the following code
> at the end of org/apache/shale/usecases/locale/Select.java overriding the
> "do-nothing" init() from ActionViewController.
>public void init()
>{
> System.out.println("Select.java - Init - PostBack Value: " +
> Boolean.toString(isPostBack()));
>}
> redeployed and ran. The console output when I click on "Select Language" link
> 15:20:27,515 INFO [STDOUT] Select.java - Init - PostBack Value: false
> 15:20:27,515 INFO [STDOUT] Select.java - Init - PostBack Value: false
> and on sumbit (when I click on "Go" )
> 15:20:33,546 INFO [STDOUT] Select.java - Init - PostBack Value: false
> 15:20:33,562 INFO [STDOUT] Select.java - Init - PostBack Value: true
> My environment is :
> OS : Windows XP Home
> JBOSS 4.0.4 Patch1 with Tomcat 5.5
> JRE : 1.5.0_06
> Eclipse 3.1.1
> Thanks
> Vish
> ==
> I was able to reproduce this with latest trunk bits, using the default
> testing configuration (MyFaces, Tomcat 5.5). It's clearly a bug in how init
> and destroy method callbacks are being triggered for view controllers, most
> likely related to the fact that the mechanism for this was recently changed.
--
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
[jira] Reopened: (SHALE-220) init() lifecycle method called twice
[ http://issues.apache.org/struts/browse/SHALE-220?page=all ]
Craig McClanahan reopened SHALE-220:
Reopening, as Bob Butash reports similar symptoms when using 1.0.3.
> init() lifecycle method called twice
>
>
> Key: SHALE-220
> URL: http://issues.apache.org/struts/browse/SHALE-220
> Project: Shale
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Craig McClanahan
> Assigned To: Craig McClanahan
> Fix For: 1.0.3
>
>
> From a user mailing list posting by Viswanath ,
> following up on earlier mailing list conversations:
> ==
> Hi Craig,
> Now that I have subscribed to Shale user group, I am posting this issue again.
> Just to make sure that I am not using older version of Shale libraries, I
> have downloaded shale-framework-20060713.zip and tried, same problem. This is
> what I did, to reproduce the issue in usecases project. ( I am not able to
> post code from my project because of lot of dependencies on EJBs/Database)
> I downloaded the latest usecases zip (07/14/2006). Unzipped the war file into
> a directory, created a project in eclipse, added the java source files,
> built and deployed it into JBOSS and it ran fine. Added the following code
> at the end of org/apache/shale/usecases/locale/Select.java overriding the
> "do-nothing" init() from ActionViewController.
>public void init()
>{
> System.out.println("Select.java - Init - PostBack Value: " +
> Boolean.toString(isPostBack()));
>}
> redeployed and ran. The console output when I click on "Select Language" link
> 15:20:27,515 INFO [STDOUT] Select.java - Init - PostBack Value: false
> 15:20:27,515 INFO [STDOUT] Select.java - Init - PostBack Value: false
> and on sumbit (when I click on "Go" )
> 15:20:33,546 INFO [STDOUT] Select.java - Init - PostBack Value: false
> 15:20:33,562 INFO [STDOUT] Select.java - Init - PostBack Value: true
> My environment is :
> OS : Windows XP Home
> JBOSS 4.0.4 Patch1 with Tomcat 5.5
> JRE : 1.5.0_06
> Eclipse 3.1.1
> Thanks
> Vish
> ==
> I was able to reproduce this with latest trunk bits, using the default
> testing configuration (MyFaces, Tomcat 5.5). It's clearly a bug in how init
> and destroy method callbacks are being triggered for view controllers, most
> likely related to the fact that the mechanism for this was recently changed.
--
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
[jira] Commented: (SHALE-297) Client Validation on objects within JSF Datatable
[
http://issues.apache.org/struts/browse/SHALE-297?page=comments#action_38310 ]
Gary VanMatre commented on SHALE-297:
-
I suspect that the reason that your example didn't work using the 1.0.3 shale
build has to do with your dependencies.
The shale validator requires commons validator 1.3. You can see a working
example of what you have reported in the shale-usecases. You can find that
here: http://people.apache.org/dist/shale/v1.0.3/shale-usecases-1.0.3.zip
There are some difference between this example and the fragment you have
posted. This example uses myfaces 1.1.1 and doesn't use the tomahawk
components.
However, I modified this example in my own testbed to use myfaces 1.1.3 and
tomahawk 1.1.3. I even tested using the super slick component and
I didn't see any problems.
A snippet of the javascript from this test bed:
function tomSubview_tomForm_required() {
this[0] = new Array("tomSubview:tomForm:tomDataTable:0:_idJsp33:0:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
this[1] = new Array("tomSubview:tomForm:tomDataTable:0:_idJsp33:1:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
this[2] = new Array("tomSubview:tomForm:tomDataTable:1:_idJsp33:0:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
this[3] = new Array("tomSubview:tomForm:tomDataTable:1:_idJsp33:1:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
this[4] = new Array("tomSubview:tomForm:tomDataTable:2:_idJsp33:0:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
this[5] = new Array("tomSubview:tomForm:tomDataTable:2:_idJsp33:1:_idJsp34",
"CPT is required.", new Function("x", "return {arg:'CPT'}[x];"));
}
Please take a look the shale-usecases.war in the 1.0.3 archive above and
compare it with your example. That might help isolate your particular problem.
> Client Validation on objects within JSF Datatable
> -
>
> Key: SHALE-297
> URL: http://issues.apache.org/struts/browse/SHALE-297
> Project: Shale
> Issue Type: Bug
>Affects Versions: 1.0.2
> Environment: Shale 1.0.2, JDK 1.5.0_05, myfaces tomahawk 1.1.3,
> weblogic 9.2, Windoxs XP Professional
>Reporter: Abdul Subahan
> Fix For: 1.0.3
>
>
> Unable to validate objects which are inside the jsf datatable.
> Below Sample code causes javascript and ignores total javascript validation.
>var="ilist" value="#{test.arr}" >
>
>
> server="true" client="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
[jira] Resolved: (SHALE-296) lifecycleListener removes too many servletRequest attributes in case of requestDestroyed
[ http://issues.apache.org/struts/browse/SHALE-296?page=all ] Craig McClanahan resolved SHALE-296. Fix Version/s: 1.0.4-SNAPSHOT Resolution: Fixed Fixed in nightly build 20060930. I modified your patch slightly to include instances of ViewController (as well as AbstractRequestBean) because we want to trigger destroy() callbacks on both of these. > lifecycleListener removes too many servletRequest attributes in case of > requestDestroyed > > > Key: SHALE-296 > URL: http://issues.apache.org/struts/browse/SHALE-296 > Project: Shale > Issue Type: Bug > Components: Core >Reporter: Mario Ivankovits >Priority: Blocker > Fix For: 1.0.4-SNAPSHOT > > Attachments: lifecycle_removed_attrs.diff > > > one side effect is, that a error page which should be shown is no longer > possible to view the exception as the lifecycleListener has removed it from > the map. > From the comment a few lines above the code piece in queston I guessed what > was the original intention. -- 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
[jira] Created: (SHALE-299) Refactor functionality from shale-core into separate modules
Refactor functionality from shale-core into separate modules Key: SHALE-299 URL: http://issues.apache.org/struts/browse/SHALE-299 Project: Shale Issue Type: Task Components: Core Reporter: Craig McClanahan Fix For: 1.0.4-SNAPSHOT To improve the ability of users to select which pieces of Shale functionality they wish to use, split the following functional subsets out of shale-core into their own (new) modules: * shale-application -- Application controller features * shale-validator -- Integration with Commons Validator * shale-view -- View controller, exception handling, application callbacks -- 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
[jira] Created: (SHALE-300) Import "dialog2" functionality from sandbox back into framework
Import "dialog2" functionality from sandbox back into framework --- Key: SHALE-300 URL: http://issues.apache.org/struts/browse/SHALE-300 Project: Shale Issue Type: Task Components: Dialog Reporter: Craig McClanahan Fix For: 1.0.4-SNAPSHOT Based on successful re-implementation of the dialog manager functionality in the sandbox, remove the existing implementation (org.apache.shale.dialog.*) and import the following sandbox modules back into the main framework: * shale-dialog2 --> shale-dialog * shale-dialog2-legacy --> shale-dialog-basic * shale-dialog2-scxml --> shale-dialog-scxml NOTE - this should have minimal impact on existing applications that only use the old public APIs, but *will* impact applications that have used internal interfaces. -- 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
[jira] Updated: (SHALE-301) scan configures packages or jar files only
[ http://issues.apache.org/struts/browse/SHALE-301?page=all ] Mario Ivankovits updated SHALE-301: --- Attachment: configurable_scan_packages.diff > scan configures packages or jar files only > --- > > Key: SHALE-301 > URL: http://issues.apache.org/struts/browse/SHALE-301 > Project: Shale > Issue Type: New Feature > Components: Tiger >Reporter: Mario Ivankovits > Attachments: configurable_scan_packages.diff > > > Attached you will find a patch which allows to configure which packages or > jar files shale-tiger should scan during startup. > The idea behind this patch is to improve the startup times of shale-tiger, > though, this requires to have a good insight when used with 3rd party > libraries. But the faster startup time one might get is especially during > development worth it. > If the context configuration parameter is missing, the old scanning behaviour > will be used. > A example for the configuration parameter: > > org.apache.shale.tiger.SCAN_PACKAGES > > com.ops.Contact.backings,com.ops.OPSJ.jsflib,shale-tiger-1.0.4-dev.jar > > This example means: > * Scan all classes in "com.ops.Contact.backings" (and its children) > * Scan all classes in "com.ops.OPSJ.jsflib" (and its children) > * Scann all classes in "shale-tiger-1.0.4-dev.jar" > Using the above configuration speedup the startup from shale-tiger from 4.5 > seconds to 0.5 seconds (for our application in development mode with 1461 > classes in WEB-INF/classes and 91 dependencies in WEB-iNF/lib) > old behaviour: > 2006-09-29 21:08:08,286 INFO [main] faces.LifecycleListener2 - Starting up > Shale Tiger extensions > 2006-09-29 21:08:12,847 INFO [main] faces.LifecycleListener2 - Startup of > Shale Tiger extensions is complete > new behaviour: > 2006-09-29 21:09:32,018 INFO [main] faces.LifecycleListener2 - Starting up > Shale Tiger extensions > 2006-09-29 21:09:32,506 INFO [main] faces.LifecycleListener2 - Startup of > Shale Tiger extensions is complete > The patch is meant as a start for a discussion, once we found that this > should go into the codebase I'll try to figure out how to create a test case > and a better documentation for it. -- 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
[jira] Created: (SHALE-301) scan configures packages or jar files only
scan configures packages or jar files only --- Key: SHALE-301 URL: http://issues.apache.org/struts/browse/SHALE-301 Project: Shale Issue Type: New Feature Components: Tiger Reporter: Mario Ivankovits Attachments: configurable_scan_packages.diff Attached you will find a patch which allows to configure which packages or jar files shale-tiger should scan during startup. The idea behind this patch is to improve the startup times of shale-tiger, though, this requires to have a good insight when used with 3rd party libraries. But the faster startup time one might get is especially during development worth it. If the context configuration parameter is missing, the old scanning behaviour will be used. A example for the configuration parameter: org.apache.shale.tiger.SCAN_PACKAGES com.ops.Contact.backings,com.ops.OPSJ.jsflib,shale-tiger-1.0.4-dev.jar This example means: * Scan all classes in "com.ops.Contact.backings" (and its children) * Scan all classes in "com.ops.OPSJ.jsflib" (and its children) * Scann all classes in "shale-tiger-1.0.4-dev.jar" Using the above configuration speedup the startup from shale-tiger from 4.5 seconds to 0.5 seconds (for our application in development mode with 1461 classes in WEB-INF/classes and 91 dependencies in WEB-iNF/lib) old behaviour: 2006-09-29 21:08:08,286 INFO [main] faces.LifecycleListener2 - Starting up Shale Tiger extensions 2006-09-29 21:08:12,847 INFO [main] faces.LifecycleListener2 - Startup of Shale Tiger extensions is complete new behaviour: 2006-09-29 21:09:32,018 INFO [main] faces.LifecycleListener2 - Starting up Shale Tiger extensions 2006-09-29 21:09:32,506 INFO [main] faces.LifecycleListener2 - Startup of Shale Tiger extensions is complete The patch is meant as a start for a discussion, once we found that this should go into the codebase I'll try to figure out how to create a test case and a better documentation for it. -- 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
[jira] Commented: (SHALE-292) Clay doesn't consider file's encoding when loading/parsing html templates from hdd
[ http://issues.apache.org/struts/browse/SHALE-292?page=comments#action_38313 ] Tom Pasierb commented on SHALE-292: --- I have tried the updated clay version with html templates. I experimented with -Dfile.encoding (system encoding setting), org.apache.shale.clay.HTML_TEMPLATE_CHARSET context init parameter and <-- ### clay:page charset="UTF-8" /### --> and everything works as expected so I guess this issue can be closed. Thanks Gary :-) > Clay doesn't consider file's encoding when loading/parsing html templates > from hdd > -- > > Key: SHALE-292 > URL: http://issues.apache.org/struts/browse/SHALE-292 > Project: Shale > Issue Type: Bug > Components: Clay >Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.4-SNAPSHOT, 1.0.3 > Environment: windows xp, tomcat 5.5 (started with > -Dfile.encoding=UTF-8 option, this way myfaces doesn't convert all non-ascii > characters to html entities), myfaces 1.1.3 >Reporter: Tom Pasierb > Assigned To: Gary VanMatre > Attachments: some.html, whatever.jsp > > > Clay reads html files assuming ascii encoding. This way it's impossible to > have characters other than ascii in templates. They do not display correctly. > As indicated on the user mailing list a Reader object should be used for > reading templates instead of InputStream. I wrote more about this on shale > user mailing list. > We probably need: > 1. app wide config option for setting encoding clay should use for reading > templates in. Clay would default to this setting unless maybe > 2. some per file encoding config option was set (something similar to @page > pageEncoding directive for jsps) > I marked it as major as this should be corrected if one wants to develop > localized applications with non-ascii characters in html templates. > As noted by Craig this probably also applies to xml templates, which I > haven't tried myself. -- 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
[jira] Commented: (SHALE-301) scan configures packages or jar files only
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38315 ] Mario Ivankovits commented on SHALE-301: The next idea comming into my mind is a tool which will scan the classpath and prints all packages containing classes with a shale-tiger annotation. In case of 3rd party libraries any developer should then be able to figure out the SCAN_PACKAGES configuration string easily. > scan configures packages or jar files only > --- > > Key: SHALE-301 > URL: http://issues.apache.org/struts/browse/SHALE-301 > Project: Shale > Issue Type: New Feature > Components: Tiger >Reporter: Mario Ivankovits > Attachments: configurable_scan_packages.diff > > > Attached you will find a patch which allows to configure which packages or > jar files shale-tiger should scan during startup. > The idea behind this patch is to improve the startup times of shale-tiger, > though, this requires to have a good insight when used with 3rd party > libraries. But the faster startup time one might get is especially during > development worth it. > If the context configuration parameter is missing, the old scanning behaviour > will be used. > A example for the configuration parameter: > > org.apache.shale.tiger.SCAN_PACKAGES > > com.ops.Contact.backings,com.ops.OPSJ.jsflib,shale-tiger-1.0.4-dev.jar > > This example means: > * Scan all classes in "com.ops.Contact.backings" (and its children) > * Scan all classes in "com.ops.OPSJ.jsflib" (and its children) > * Scann all classes in "shale-tiger-1.0.4-dev.jar" > Using the above configuration speedup the startup from shale-tiger from 4.5 > seconds to 0.5 seconds (for our application in development mode with 1461 > classes in WEB-INF/classes and 91 dependencies in WEB-iNF/lib) > old behaviour: > 2006-09-29 21:08:08,286 INFO [main] faces.LifecycleListener2 - Starting up > Shale Tiger extensions > 2006-09-29 21:08:12,847 INFO [main] faces.LifecycleListener2 - Startup of > Shale Tiger extensions is complete > new behaviour: > 2006-09-29 21:09:32,018 INFO [main] faces.LifecycleListener2 - Starting up > Shale Tiger extensions > 2006-09-29 21:09:32,506 INFO [main] faces.LifecycleListener2 - Startup of > Shale Tiger extensions is complete > The patch is meant as a start for a discussion, once we found that this > should go into the codebase I'll try to figure out how to create a test case > and a better documentation for it. -- 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
