[jira] [Commented] (TOBAGO-1382) New attribute "name" for
[ https://issues.apache.org/jira/browse/TOBAGO-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980200#comment-13980200 ] Hudson commented on TOBAGO-1382: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1382: New attribute "name" for (lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1583339) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/component/ObjectTag.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/component/ObjectTagDeclaration.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ObjectRenderer.java > New attribute "name" for > > > Key: TOBAGO-1382 > URL: https://issues.apache.org/jira/browse/TOBAGO-1382 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core, Themes >Affects Versions: 1.0.41, 1.5.13, 2.0.0-beta-2 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil > Fix For: 1.0.42, 1.5.14, 2.0.0-beta-3, 2.0.0, 3.0.0 > > > The name attribute of the rendered iframe will use the clientId. > The clientId usually contains a colon ":", but this doesn't work well in > JavaScript window.open(src, target) in Internet Explorer 9 and lower. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1374) link attribute contains faces mapping
[ https://issues.apache.org/jira/browse/TOBAGO-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980201#comment-13980201 ] Hudson commented on TOBAGO-1374: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1374: link attribute contains faces mapping (lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1578292) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/renderkit/html/CommandRendererHelper.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/taglib/decl/HasLink.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/util/StringUtils.java * /myfaces/tobago/branches/tobago-1.0.x/core/src/test/java/org/apache/myfaces/tobago/util/StringUtilsUnitTest.java > link attribute contains faces mapping > - > > Key: TOBAGO-1374 > URL: https://issues.apache.org/jira/browse/TOBAGO-1374 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 1.0.40, 1.5.12 >Reporter: Bernd Bohmann >Assignee: Udo Schnurpfeil > Fix For: 1.0.41, 1.5.13, 2.0.0-beta-1, 2.0.0 > > > Link contains the faces mapping. The description says only session id and > optional context path. Encode action url is called. I think this is wrong. > Link to an arbitrary URL, either an internal link or an external link. > internal absolute link > Starts with a slash '/' character. The context path will be added. A session > id will be added, if needed. > external link > Contains a colon ':' character. The link will not be modified. > internal relative link > Any other strings. A session id will be added, if needed. > Type: java.lang.String -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOBAGO-1381) Radio- and Checkbox-Renderer may produce an NullPointerException
[ https://issues.apache.org/jira/browse/TOBAGO-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980199#comment-13980199 ] Hudson commented on TOBAGO-1381: FAILURE: Integrated in tobago-1.0.x #758 (See [https://builds.apache.org/job/tobago-1.0.x/758/]) TOBAGO-1381: Radio- and Checkbox-Renderer may produce an NullPointerException (lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1583273) * /myfaces/tobago/branches/tobago-1.0.x/core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/MenuBarRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SelectManyCheckboxRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SelectOneRadioRenderer.java * /myfaces/tobago/branches/tobago-1.0.x/theme/scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/ToolBarRendererBase.java > Radio- and Checkbox-Renderer may produce an NullPointerException > > > Key: TOBAGO-1381 > URL: https://issues.apache.org/jira/browse/TOBAGO-1381 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 1.0.41, 1.5.13, 2.0.0-beta-2 >Reporter: Udo Schnurpfeil >Assignee: Udo Schnurpfeil > Fix For: 1.0.42, 1.5.14, 2.0.0-beta-3, 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MYFACES-3888) Resource from classpath locked on windows after change in eclipse
[
https://issues.apache.org/jira/browse/MYFACES-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick McLaren updated MYFACES-3888:
-
Status: Patch Available (was: Open)
> Resource from classpath locked on windows after change in eclipse
> -
>
> Key: MYFACES-3888
> URL: https://issues.apache.org/jira/browse/MYFACES-3888
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.1.12, 2.1.13, 2.1.14, 2.1.15
> Environment: Tomcat in an Eclipse on Windows environment
>Reporter: Patrick McLaren
>
> Loading a JSF page from the classpath in Tomcat in an Eclipse on Windows
> environment, then changing the JSF file via Eclipse lead to the original file
> resource being locked by the finalizer thread trying to close an InputStream
> to the file resource. After a GC the resource was overwritable again. The
> reason was the unclosed input stream in FaceletCacheImpl.java .
> The following patch fixes the issue.
> --- java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java 8 Jan
> 2013 14:28:47 - 1.2
> +++ java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java 24 Apr
> 2014 16:20:49 -
> @@ -154,9 +154,10 @@
> {
> // Should check for file modification
>
> +URLConnection conn = null;
> try
> {
> -URLConnection conn = facelet.getSource().openConnection();
> +conn = facelet.getSource().openConnection();
> long lastModified =
> ResourceLoaderUtils.getResourceLastModified(conn);
>
> return lastModified == 0 || lastModified > target;
> @@ -165,6 +166,16 @@
> {
> throw new FaceletException("Error Checking Last Modified for
> " + facelet.getAlias(), e);
> }
> +// finally close input stream when finished
> +finally {
> +if (conn != null) {
> +try {
> +conn.getInputStream().close();
> +} catch (IOException e) {
> +throw new FaceletException("Error Checking Last
> Modified for " + facelet.getAlias(), e);
> +}
> +}
> +}
> }
>
> return false;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3888) Resource from classpath locked on windows after change in eclipse
Patrick McLaren created MYFACES-3888:
Summary: Resource from classpath locked on windows after change in
eclipse
Key: MYFACES-3888
URL: https://issues.apache.org/jira/browse/MYFACES-3888
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.15, 2.1.14, 2.1.13, 2.1.12
Environment: Tomcat in an Eclipse on Windows environment
Reporter: Patrick McLaren
Loading a JSF page from the classpath in Tomcat in an Eclipse on Windows
environment, then changing the JSF file via Eclipse lead to the original file
resource being locked by the finalizer thread trying to close an InputStream to
the file resource. After a GC the resource was overwritable again. The reason
was the unclosed input stream in FaceletCacheImpl.java .
The following patch fixes the issue.
--- java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java8 Jan
2013 14:28:47 - 1.2
+++ java/org/apache/myfaces/view/facelets/impl/FaceletCacheImpl.java24 Apr
2014 16:20:49 -
@@ -154,9 +154,10 @@
{
// Should check for file modification
+URLConnection conn = null;
try
{
-URLConnection conn = facelet.getSource().openConnection();
+conn = facelet.getSource().openConnection();
long lastModified =
ResourceLoaderUtils.getResourceLastModified(conn);
return lastModified == 0 || lastModified > target;
@@ -165,6 +166,16 @@
{
throw new FaceletException("Error Checking Last Modified for "
+ facelet.getAlias(), e);
}
+// finally close input stream when finished
+finally {
+if (conn != null) {
+try {
+conn.getInputStream().close();
+} catch (IOException e) {
+throw new FaceletException("Error Checking Last
Modified for " + facelet.getAlias(), e);
+}
+}
+}
}
return false;
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TOBAGO-1390) "Can't parse to any measure"
[
https://issues.apache.org/jira/browse/TOBAGO-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979796#comment-13979796
]
Udo Schnurpfeil edited comment on TOBAGO-1390 at 4/24/14 2:54 PM:
--
I think the best way is a combination of a) and b)
b) to generally prevent for such problems and
a) to round up or down correctly (which can't be decided in b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
was (Author: lofwyr):
I think the best way is b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
> "Can't parse to any measure"
>
>
> Key: TOBAGO-1390
> URL: https://issues.apache.org/jira/browse/TOBAGO-1390
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-beta-2
> Environment: Firefox 28.0
>Reporter: Bernhard Stadler
>Assignee: Udo Schnurpfeil
> Fix For: 2.0.0-beta-3
>
>
> In our application, there are frequent occurences of
> IllegalArgumentExceptions in org.apache.myfaces.tobago.layout.Measure line
> 79 (function valueOf(String)), which is being called by
> org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
> decodePageState(FacesContext, AbstractUIPage)).
> I wasn't able to create a reproducing example, but I have been able to
> isolate the conditions and causes under which this happens in our application:
> Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
> sending decimal values (e.g. "1298.4px") as positions or dimensions.
> Measure.valueOf only checks whether the String received ends with "px" and
> removes it if necessary, but doesn't have any means to handle decimals.
> In the JavaScript code, I found out that the non-integer value stems from the
> following lines in function augmentWidthOrHeight( elem, name, extra,
> isBorderBox, styles ) in jquery-1.10.2.js:
> {code}
> // at this point, extra isn't border nor margin, so remove border
> if ( extra !== "margin" ) {
> val -= jQuery.css( elem, "border" + cssExpand[ i ] + "Width", true, styles
> );
> }
> {code}
> Removing the following lines from our CSS file seems to stop the errors from
> occurring:
> {code}
> .tobago-page {
> width: 90%;
> height: 99%;
> // ...
> }
> {code}
> I'm not sure whether this is a correct use of CSS but I guess it shouldn't
> cause a RuntimeException, especially as it is caused by unsanitized client
> data.
> I don't know what the best course of action might be:
> a) Change the JavaScript code to remove decimal places
> b) Change Measure to remove decimal places
> c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOBAGO-1390) "Can't parse to any measure"
[
https://issues.apache.org/jira/browse/TOBAGO-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979796#comment-13979796
]
Udo Schnurpfeil commented on TOBAGO-1390:
-
I think the best way is b)
BTW: Using % values are allowed, but potentially problematic, so I don't use it
;-)
> "Can't parse to any measure"
>
>
> Key: TOBAGO-1390
> URL: https://issues.apache.org/jira/browse/TOBAGO-1390
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-beta-2
> Environment: Firefox 28.0
>Reporter: Bernhard Stadler
>
> In our application, there are frequent occurences of
> IllegalArgumentExceptions in org.apache.myfaces.tobago.layout.Measure line
> 79 (function valueOf(String)), which is being called by
> org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
> decodePageState(FacesContext, AbstractUIPage)).
> I wasn't able to create a reproducing example, but I have been able to
> isolate the conditions and causes under which this happens in our application:
> Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
> sending decimal values (e.g. "1298.4px") as positions or dimensions.
> Measure.valueOf only checks whether the String received ends with "px" and
> removes it if necessary, but doesn't have any means to handle decimals.
> In the JavaScript code, I found out that the non-integer value stems from the
> following lines in function augmentWidthOrHeight( elem, name, extra,
> isBorderBox, styles ) in jquery-1.10.2.js:
> {code}
> // at this point, extra isn't border nor margin, so remove border
> if ( extra !== "margin" ) {
> val -= jQuery.css( elem, "border" + cssExpand[ i ] + "Width", true, styles
> );
> }
> {code}
> Removing the following lines from our CSS file seems to stop the errors from
> occurring:
> {code}
> .tobago-page {
> width: 90%;
> height: 99%;
> // ...
> }
> {code}
> I'm not sure whether this is a correct use of CSS but I guess it shouldn't
> cause a RuntimeException, especially as it is caused by unsanitized client
> data.
> I don't know what the best course of action might be:
> a) Change the JavaScript code to remove decimal places
> b) Change Measure to remove decimal places
> c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOBAGO-1388) Wandering popup
[
https://issues.apache.org/jira/browse/TOBAGO-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979759#comment-13979759
]
Udo Schnurpfeil commented on TOBAGO-1388:
-
It seems to use position() instead of offset() resolves the problem. I've
commited the change to the trunk.
> Wandering popup
> ---
>
> Key: TOBAGO-1388
> URL: https://issues.apache.org/jira/browse/TOBAGO-1388
> Project: MyFaces Tobago
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-1
> Environment: Custom Theme
>Reporter: Bernhard Stadler
>Assignee: Udo Schnurpfeil
> Attachments: PopupTestModel.java, popuptabletest.xhtml
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I have a tc:page containing a tc:popup with a tc:sheet inside. For the sheet,
> paging is enabled. I'll attach an example.
> Every time the page is changed, the popup changes its position for some
> amount.
> We have a custom theme and I was able to isolate the following definitions in
> our tobago.css file which lay open the problem:
> {code}
> .tobago-page {
> border: 1px solid #EE;
> width: 90%;
> height: 99%;
> // ...
> }
> {code}
> Each of these lines alone causes some amount of popup movement. Removing all
> of them makes the problem disappear.
> I also was able to isolate the JavaScript code where the actual repositioning
> happens:
> tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-utils.js
> Tobago.Utils.keepElementInVisibleArea line 98f (SVN trunk):
> {code}
> /**
> * fix position, when the element it is outside of the current page
> * @param elements is an jQuery Array of elements to be fixed.
> */
> Tobago.Utils.keepElementInVisibleArea = function(elements) {
> elements.each(function() {
> var element = jQuery(this);
> var page = jQuery(".tobago-page-content:first");
> var left = element.offset().left;
> var top = element.offset().top;
> // fix menu position, when it is outside of the current page
> left = Math.max(0, Math.min(left, page.outerWidth() -
> element.outerWidth()));
> top = Math.max(0, Math.min(top, page.outerHeight() -
> element.outerHeight()));
> element.css('left', left);
> element.css('top', top);
> });
> };
> {code}
> The "left" and "top" variables are not changed by the max/min assignment, but
> because of (both!) the border and the changed width of the tobago-page class,
> element.offset().left and element.offset().top seem to return a different
> value than actually needed. Even the following code causes the same behavior:
> {code}
> Tobago.Utils.keepElementInVisibleArea = function(elements) {
> elements.each(function() {
> var element = jQuery(this);
> element.css('left', element.offset().left);
> element.css('top', element.offset().top);
> });
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TOBAGO-1390) "Can't parse to any measure"
Bernhard Stadler created TOBAGO-1390:
Summary: "Can't parse to any measure"
Key: TOBAGO-1390
URL: https://issues.apache.org/jira/browse/TOBAGO-1390
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-2
Environment: Firefox 28.0
Reporter: Bernhard Stadler
In our application, there are frequent occurences of IllegalArgumentExceptions
in org.apache.myfaces.tobago.layout.Measure line 79 (function
valueOf(String)), which is being called by
org.apache.myfaces.tobago.renderkit.PageRendererBase line 86 (function
decodePageState(FacesContext, AbstractUIPage)).
I wasn't able to create a reproducing example, but I have been able to isolate
the conditions and causes under which this happens in our application:
Apparently it is caused by JavaScript code (tobago.js, storeClientDimension)
sending decimal values (e.g. "1298.4px") as positions or dimensions.
Measure.valueOf only checks whether the String received ends with "px" and
removes it if necessary, but doesn't have any means to handle decimals.
In the JavaScript code, I found out that the non-integer value stems from the
following lines in function augmentWidthOrHeight( elem, name, extra,
isBorderBox, styles ) in jquery-1.10.2.js:
{code}
// at this point, extra isn't border nor margin, so remove border
if ( extra !== "margin" ) {
val -= jQuery.css( elem, "border" + cssExpand[ i ] + "Width", true, styles );
}
{code}
Removing the following lines from our CSS file seems to stop the errors from
occurring:
{code}
.tobago-page {
width: 90%;
height: 99%;
// ...
}
{code}
I'm not sure whether this is a correct use of CSS but I guess it shouldn't
cause a RuntimeException, especially as it is caused by unsanitized client
data.
I don't know what the best course of action might be:
a) Change the JavaScript code to remove decimal places
b) Change Measure to remove decimal places
c) Change Measure to actually store decimals instead of integers
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TOBAGO-1389) Disable Hotkey-Behaviour
Matthias Wronka created TOBAGO-1389: --- Summary: Disable Hotkey-Behaviour Key: TOBAGO-1389 URL: https://issues.apache.org/jira/browse/TOBAGO-1389 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Matthias Wronka Priority: Minor Whenever a label (e.g. of a tx:in) contains a underscore (_), tobago creates a hotkey (alt + ) for the corresponding input-field. However, this is not always the desired behaviour e.g. for generic frontends where the labels are not controlled by the developer. I would appreciate a possibility to deactivate this feature globally. Furthermore an explicit way to configure HotKeys (e.g. via an extra-attribute) would be great. This would also enable the application to use the same hotkeys in multi-language-applications (like Ctrl+P is used for "Drucken" in german applications) -- This message was sent by Atlassian JIRA (v6.2#6252)
