[JBoss JIRA] (RF-12583) Typo in the makePatternAMatch CSV javascript function
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12583?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12583.
--------------------------------
Resolution: Done
> Typo in the makePatternAMatch CSV javascript function
> -----------------------------------------------------
>
> Key: RF-12583
> URL: https://issues.jboss.org/browse/RF-12583
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.1.0.Milestone4
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.2.4, 4.3.0.M3
>
>
> The _makePatternAMatch_ function was introduced in resolution to RF-11531. however that method has a typo in it. See the extra ";" in the second _pattern_ assignment.
> {code}
> var makePatternAMatch = function(pattern) {
> if (! (pattern.slice(0, 1) === '^') ) {
> pattern = '^' + pattern;
> }
> if (! (pattern.slice(-1) === '$') ) {
> pattern = pattern; + '$';
> }
> return pattern;
> }
> {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
11 years, 11 months
[JBoss JIRA] (RF-12583) Typo in the makePatternAMatch CSV javascript function
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12583?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12583:
-------------------------------
Component/s: component-validators
> Typo in the makePatternAMatch CSV javascript function
> -----------------------------------------------------
>
> Key: RF-12583
> URL: https://issues.jboss.org/browse/RF-12583
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.1.0.Milestone4
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.2.4, 4.3.0.M3
>
>
> The _makePatternAMatch_ function was introduced in resolution to RF-11531. however that method has a typo in it. See the extra ";" in the second _pattern_ assignment.
> {code}
> var makePatternAMatch = function(pattern) {
> if (! (pattern.slice(0, 1) === '^') ) {
> pattern = '^' + pattern;
> }
> if (! (pattern.slice(-1) === '$') ) {
> pattern = pattern; + '$';
> }
> return pattern;
> }
> {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
11 years, 11 months
[JBoss JIRA] (RF-12608) pickList without collectionType results in failure to lazily load
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12608?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12608.
--------------------------------
Resolution: Done
> pickList without collectionType results in failure to lazily load
> -----------------------------------------------------------------
>
> Key: RF-12608
> URL: https://issues.jboss.org/browse/RF-12608
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-selects
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Reporter: Ken H
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.0.CR1
>
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> Changes to the selectManyHelper class in 4.2.3+ causes a lazy loading exception in hibernate when the backing collection is persistent and is not eagerly loaded.
> The problem seems to be that fetching the collection in SelectManyHelper.getConvertedValue bypasses the PersistentSet getter that would normally issue the lazy load request.
> Defining the collectionType (e.g. java.util.ArrayList) bypasses this issue.
> Ideally this method would detect Hibernate proxy collections and handle them appropriately. However, I realize that may cause a dependency so perhaps it would be enough to document this option and situation in the component reference.
> The stack trace for the exception is below:
> {code}
> [org.richfaces.log.Context] (http-localhost-127.0.0.1-8080-1) failed to lazily initialize a collection, no session or session was closed: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed
> at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:393) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:385) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:378) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.write(AbstractPersistentCollection.java:208) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.PersistentBag.add(PersistentBag.java:291) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.richfaces.renderkit.SelectManyHelper.getConvertedValue(SelectManyHelper.java:350) [richfaces-components-ui-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.renderkit.SelectManyRendererBase.getConvertedValue(SelectManyRendererBase.java:108) [richfaces-components-ui-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1030) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.validate(UIInput.java:960) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.executeValidate(UIInput.java:1233) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.processValidators(UIInput.java:698) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIForm.processValidators(UIForm.java:253) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at org.richfaces.context.PartialViewExecuteVisitCallback.visit(PartialViewExecuteVisitCallback.java:55) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.BaseExtendedVisitContext.invokeVisitCallback(BaseExtendedVisitContext.java:321) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1612) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIForm.visitTree(UIForm.java:371) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.executeComponents(ExtendedPartialViewContextImpl.java:237) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.processPartialExecutePhase(ExtendedPartialViewContextImpl.java:217) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:196) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1170) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76) [jsf-impl-2.1.7-jbossorg-2.jar:]
> {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
11 years, 11 months
[JBoss JIRA] (RF-5460) Strange a4j resource prefix with url-based servlet mappings
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-5460?page=com.atlassian.jira.plugin.sy... ]
Brian Leathem updated RF-5460:
------------------------------
Component/s: core
> Strange a4j resource prefix with url-based servlet mappings
> -----------------------------------------------------------
>
> Key: RF-5460
> URL: https://issues.jboss.org/browse/RF-5460
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 3.2.2
> Environment: JSF RI 1.2.11, RF 3.2.2SR1, Facelets 1.1.15b1, Glassfish v2.
> Reporter: Fab Mars
> Priority: Minor
> Labels: a4j, mapping, prefix, servlet
>
> My web.xml has several servlet mappings.
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath1/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath999/*</url-pattern>
> </servlet-mapping>
> I'm doing this because I'm using some phaselistener that preproceses some things and also enables short-urls.
> Now, any page has a4j resources written like this:
> <script type="text/javascript" src="/MyContext/somepath999/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js">
> That is all a4j resources are now comprising the LAST servlet-mapping, just between the context name and the /a4j/ path part.
> I tried to workaround it, by putting the *.jsf mapping as the last in the web.xml but to no avail: the last servlet mapping path was always used.
> To reproduce, just download the demo application: http://download.jboss.com/jboss-richfaces/richfaces-demo-3.2.2.SR1-jee5.war
> Edit web.xml and add to the existing *.jsf mapping the following:
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/yeswecan/*</url-pattern>
> </servlet-mapping>
> Then deploy and look at the source of any page:
> <img class="rich-spacer " height="1" id="j_id258" src="/richfaces/yeswecan/a4j/g/3_2_2.SR1images/spacer.gif" width="1" style="height:10px;" />
> I'm not sure this is a bug or a feature of some sort. The code obviously takes ANY valid servlet mapping, which is fair enough. But maybe it should just check whether there is an extension-based mapping amongst them, and if yes, use it.
> Worse, this issue is also probably (conceptually) linked to https://jira.jboss.org/jira/browse/RF-3586
> Anyway, you're free to requalify this issue if you want. I'm reporting what I found and I'll find a workaround in the meantime.
> Thanks.
--
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
11 years, 11 months
[JBoss JIRA] (RF-5460) Strange a4j resource prefix with url-based servlet mappings
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-5460?page=com.atlassian.jira.plugin.sy... ]
Brian Leathem resolved RF-5460.
-------------------------------
Resolution: Done
> Strange a4j resource prefix with url-based servlet mappings
> -----------------------------------------------------------
>
> Key: RF-5460
> URL: https://issues.jboss.org/browse/RF-5460
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 3.2.2
> Environment: JSF RI 1.2.11, RF 3.2.2SR1, Facelets 1.1.15b1, Glassfish v2.
> Reporter: Fab Mars
> Priority: Minor
> Labels: a4j, mapping, prefix, servlet
>
> My web.xml has several servlet mappings.
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath1/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath999/*</url-pattern>
> </servlet-mapping>
> I'm doing this because I'm using some phaselistener that preproceses some things and also enables short-urls.
> Now, any page has a4j resources written like this:
> <script type="text/javascript" src="/MyContext/somepath999/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js">
> That is all a4j resources are now comprising the LAST servlet-mapping, just between the context name and the /a4j/ path part.
> I tried to workaround it, by putting the *.jsf mapping as the last in the web.xml but to no avail: the last servlet mapping path was always used.
> To reproduce, just download the demo application: http://download.jboss.com/jboss-richfaces/richfaces-demo-3.2.2.SR1-jee5.war
> Edit web.xml and add to the existing *.jsf mapping the following:
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/yeswecan/*</url-pattern>
> </servlet-mapping>
> Then deploy and look at the source of any page:
> <img class="rich-spacer " height="1" id="j_id258" src="/richfaces/yeswecan/a4j/g/3_2_2.SR1images/spacer.gif" width="1" style="height:10px;" />
> I'm not sure this is a bug or a feature of some sort. The code obviously takes ANY valid servlet mapping, which is fair enough. But maybe it should just check whether there is an extension-based mapping amongst them, and if yes, use it.
> Worse, this issue is also probably (conceptually) linked to https://jira.jboss.org/jira/browse/RF-3586
> Anyway, you're free to requalify this issue if you want. I'm reporting what I found and I'll find a workaround in the meantime.
> Thanks.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12608) pickList without collectionType results in failure to lazily load
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12608?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12608:
-------------------------------
Component/s: component-selects
> pickList without collectionType results in failure to lazily load
> -----------------------------------------------------------------
>
> Key: RF-12608
> URL: https://issues.jboss.org/browse/RF-12608
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-selects
> Affects Versions: 4.2.3.Final, 4.3.0.M2
> Reporter: Ken H
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.0.CR1
>
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> Changes to the selectManyHelper class in 4.2.3+ causes a lazy loading exception in hibernate when the backing collection is persistent and is not eagerly loaded.
> The problem seems to be that fetching the collection in SelectManyHelper.getConvertedValue bypasses the PersistentSet getter that would normally issue the lazy load request.
> Defining the collectionType (e.g. java.util.ArrayList) bypasses this issue.
> Ideally this method would detect Hibernate proxy collections and handle them appropriately. However, I realize that may cause a dependency so perhaps it would be enough to document this option and situation in the component reference.
> The stack trace for the exception is below:
> {code}
> [org.richfaces.log.Context] (http-localhost-127.0.0.1-8080-1) failed to lazily initialize a collection, no session or session was closed: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed
> at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:393) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:385) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:378) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.AbstractPersistentCollection.write(AbstractPersistentCollection.java:208) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.hibernate.collection.internal.PersistentBag.add(PersistentBag.java:291) [hibernate-core-4.0.1.Final.jar:4.0.1.Final]
> at org.richfaces.renderkit.SelectManyHelper.getConvertedValue(SelectManyHelper.java:350) [richfaces-components-ui-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.renderkit.SelectManyRendererBase.getConvertedValue(SelectManyRendererBase.java:108) [richfaces-components-ui-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1030) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.validate(UIInput.java:960) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.executeValidate(UIInput.java:1233) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIInput.processValidators(UIInput.java:698) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1214) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIForm.processValidators(UIForm.java:253) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at org.richfaces.context.PartialViewExecuteVisitCallback.visit(PartialViewExecuteVisitCallback.java:55) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.BaseExtendedVisitContext.invokeVisitCallback(BaseExtendedVisitContext.java:321) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1612) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIForm.visitTree(UIForm.java:371) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.executeComponents(ExtendedPartialViewContextImpl.java:237) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.processPartialExecutePhase(ExtendedPartialViewContextImpl.java:217) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:196) [richfaces-core-impl-4.2.3.Final.jar:4.2.3.Final]
> at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1170) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
> at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76) [jsf-impl-2.1.7-jbossorg-2.jar:]
> {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
11 years, 11 months