[JBoss JIRA] (RF-13436) Upgrade CKEditor to 4.3 (and switch code to jQuery Widget Factory)
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13436?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13436:
----------------------------
Summary: Upgrade CKEditor to 4.3 (and switch code to jQuery Widget Factory) (was: Upgrade CKEditor to 4.3)
> Upgrade CKEditor to 4.3 (and switch code to jQuery Widget Factory)
> ------------------------------------------------------------------
>
> Key: RF-13436
> URL: https://issues.jboss.org/browse/RF-13436
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.4, 5.0.0.Alpha1
> Reporter: barbara b
> Assignee: Lukáš Fryč
> Labels: needs-qe
> Fix For: 5.0.0.Alpha4
>
>
> All current versions of Richfaces are working with CKEditor 3.6.6. Would it be possible to make an upgrade of CKEditor to a version 4.3? Some plugins for CKEditor are only working with the 4.X versions of the editor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13550) Refactor bridge-base so that it will allow bridges to extend widgets
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13550?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13550:
---------------------------------
One of the caveats:
bridge is usually called on component root, but widget can be instantiated on inner element:
{code}
<div id="editor">
<textarea id="editorInput"></textarea>
{code}
{code}
$('#editor').editorBridge(); ---> internally calls $("#editor" + 'Input').editor();
{code}
> Refactor bridge-base so that it will allow bridges to extend widgets
> --------------------------------------------------------------------
>
> Key: RF-13550
> URL: https://issues.jboss.org/browse/RF-13550
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
>
> This will allow bridges to extend widget API and make it more natural for JSF users, e.g.:
> Editor is now:
> {code}
> $.widget('rf.editorBridge', $.rf.bridgeBase,
> {code}
> but we want:
> {code}
> $.widget('rf.editorBridge', $.rich.editor,
> {code}
> On multiple inheritance in jQuery Widget Factory:
> https://forum.jquery.com/topic/how-to-extend-a-widget-factory-widget-with...
> The way of extending API should be designed in that way that user calls e.g.:
> {code}
> #{r:component('editor')}.setValue();
> {code}
> but editor has (or rather should have) only a method which is named in jQuery Widget Factory style:
> {code}
> data('editor').value() / data('editor').value(newValue)
> editor('value') / editor('value', newValue)
> {code}
> So, we want bridge to add the setValue/getValue API:
> {code}
> $.extend(widget), { setValue: ..., getValue: ...};
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13550) Refactor bridge-base so that it will allow bridges to extend widgets
by Lukáš Fryč (JIRA)
Lukáš Fryč created RF-13550:
-------------------------------
Summary: Refactor bridge-base so that it will allow bridges to extend widgets
Key: RF-13550
URL: https://issues.jboss.org/browse/RF-13550
Project: RichFaces
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: component
Affects Versions: 5.0.0.Alpha3
Reporter: Lukáš Fryč
This will allow bridges to extend widget API and make it more natural for JSF users, e.g.:
Editor is now:
{code}
$.widget('rf.editorBridge', $.rf.bridgeBase,
{code}
but we want:
{code}
$.widget('rf.editorBridge', $.rich.editor,
{code}
On multiple inheritance in jQuery Widget Factory:
https://forum.jquery.com/topic/how-to-extend-a-widget-factory-widget-with...
The way of extending API should be designed in that way that user calls e.g.:
{code}
#{r:component('editor')}.setValue();
{code}
but editor has (or rather should have) only a method which is named in jQuery Widget Factory style:
{code}
data('editor').value() / data('editor').value(newValue)
editor('value') / editor('value', newValue)
{code}
So, we want bridge to add the setValue/getValue API:
{code}
$.extend(widget), { setValue: ..., getValue: ...};
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Marcel Šebek (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Marcel Šebek commented on RF-13250:
-----------------------------------
Well, I've done some more investigations on this issue. At least one way how to leak resources is to send a malformed atmosphere request to an application. For example, send GET to /__richfaces_push?X-Atmosphere-Transport=long-polling
Then, with each such request, you should observe "Committed error code 400" and one leaked org.atmosphere.cpr.Meteor instance (it is leaked, because it is referenced from Meteor.cache). The error is probably produced by PushHandlerFilter - check for session == null.
I think it is time to reopen the bug now. If you cannot reproduce it, now I think I should be able to find the missing piece of information.
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Pavol Pitonak
> Labels: memoryleak
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13538) Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13538?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13538:
----------------------------
Forum Reference: https://community.jboss.org/thread/237087
> Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
> ---------------------------------------------------------------------
>
> Key: RF-13538
> URL: https://issues.jboss.org/browse/RF-13538
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Fix For: 5.0.0.Alpha4
>
>
> For instance in org.richfaces.resource.Java2DUserResourceWrapperImpl at line 73 is an invocation of Closeables.closeQuietly(...). However, this method is removed in Guava 16.0 which is now used in RF 5.0.0.Alpha3.
> javadoc of Guava 14.0 already mentioned:
> "Deprecated. Where possible, use the try-with-resources statement if using JDK7 or Closer on JDK6 to close one or more Closeable objects. This method is deprecated because it is easy to misuse and may swallow IO exceptions that really should be thrown and handled. See Guava issue 1118 for a more detailed explanation of the reasons for deprecation and see Closing Resources for more information on the problems with closing Closeable objects and some of the preferred solutions for handling it correctly. This method is scheduled to be removed in Guava 16.0."
> Well, now the method is removed, but still invoked in RF 5.0.0.Alpha3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13247) Upgrade the RichFaces guava dependency to the latest version
by Pavel Slegr (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Pavel Slegr commented on RF-13247:
----------------------------------
Thanks Lukas, it shows like huge codebase to be reworked, which does not have suitable replacement in JDK7 anyway...Let's make sure to use proper version of guava
then, not being in troubles at the end.... so 16.0.1 ... same as WF8 Final !?
> Upgrade the RichFaces guava dependency to the latest version
> ------------------------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Brian Leathem
> Priority: Minor
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13101) rich:select Method getSelectInputLabel is not working when using objects
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13101?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13101:
---------------------------------
[~jigg4], any chance you could provide a reproducer here? Or at least clarify how we could reproduce it?
Matej [tried|https://github.com/richfaces4/components/pull/83#issuecomment-34970700] to reproduce it here, but with no luck.
> rich:select Method getSelectInputLabel is not working when using objects
> ------------------------------------------------------------------------
>
> Key: RF-13101
> URL: https://issues.jboss.org/browse/RF-13101
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input, component-selects
> Affects Versions: 4.3.2, 5.0.0.Alpha1
> Reporter: J W
> Labels: rich:select, select
> Fix For: 4.5-Tracking
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> The condition of the if-statement in org.richfaces.renderkit.SelectHelper.getSelectInputLabel(FacesContext facesContext, UIComponent component) is not working with the string-representations of the items. If using cloned objects the equals method will return false, even if the items are the same, because the IDs are different.
> The method should use only the strings of the objects, similiar to how MyFaces has solved this (check workarround).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months