[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Fab Mars edited comment on RF-13098 at 10/14/13 5:50 AM:
---------------------------------------------------------
I added org.jboss.weld.util.el.ForwardingMethodExpression to /org/richfaces/resource/resource-serialization.properties in my own war (which is itself in an ear).
Nothing changes, I'm puzzled now (could it be a classloader issue?)
By the way I checked LookAheadObjectInputSteam#loadWhitelist() and the text of the RuntimeException on stream.close is wrong ("Error closing the ResourceBuilder.properties file").
was (Author: fabmars):
I added org.jboss.weld.util.el.ForwardingMethodExpression to /org/richfaces/resource/resource-serialization.properties in my own war (which is itself in an ear).
Nothing changes, I'm puzzled now.
By the way I checked LookAheadObjectInputSteam#loadWhitelist() and the text of the RuntimeException on stream.close is wrong ("Error closing the ResourceBuilder.properties file").
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.4, 5.0.0.Alpha2
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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
12 years, 5 months
[JBoss JIRA] (RF-13123) Compile Widget's Bridge code using Grunt
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13123?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13123 at 10/14/13 5:46 AM:
-----------------------------------------------------------
The idea was usage of Grunt to package and minify bridge code the same way as RichWidgets code is.
Then we wouldn't need Resource Optimizer.
This is just an option which needs to be weighter against other approaches, e.g. RequireJS modular resource loading.
was (Author: lfryc):
The idea was usage of Grunt to package and minify bridge code the same way as RichWidgets code is.
Then we wouldn't need Resource Optimizer.
> Compile Widget's Bridge code using Grunt
> ----------------------------------------
>
> Key: RF-13123
> URL: https://issues.jboss.org/browse/RF-13123
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Lukáš Fryč
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> We have discussed how bridge code should be compiled:
> * it should not be part of the Widgets repository
> ** as the code is dedicated to interoperability with JSF
> * it should be compiled by Grunt
> ** avoiding any Java-specific tooling
> ----
> Two options discussed so far:
> 1. create additional JS repo
> 2. use [yeoman-maven-plugin|https://github.com/trecloux/yeoman-maven-plugin]
--
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
12 years, 5 months
[JBoss JIRA] (RF-10227) autocomplete: implement "nothingLabel"
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-10227?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-10227:
---------------------------------
1) Event update allows to intercept autocompletion and read a list of available suggestions
2) Some counter-examples for not showing {{There are no suggestions}}: Google autocomplete, autocompletion built into browsers.
3) The other problem is that Autocomplete doesn't indicate whether suggestion mechanism is in progress, fortunately you can use r:status to show progress to an user. It is then evident from the status, that when there are no suggestions after completion, nothing is available.
Just to clarify, I'm not saying we shouldn't implement it, just brain-storming possible options. ;-)
Note that we will need this functionality for RF5 r:select, which means that we could share functionality with r:autocomplete.
> autocomplete: implement "nothingLabel"
> --------------------------------------
>
> Key: RF-10227
> URL: https://issues.jboss.org/browse/RF-10227
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: base functionality, component-input
> Affects Versions: 4.0.0.Milestone5
> Reporter: Juergen Zimmermann
> Fix For: 5-Future
>
>
> rich:autocomplete doesn't have an attribute for a "nothingLabel" to indicate that there are no matches
--
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
12 years, 5 months
[JBoss JIRA] (RF-13246) Richfaces 4.3.4 ajax fails on ie8 packed.js cannot find console.
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13246?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek commented on RF-13246:
----------------------------------
Cannot reproduce this.
Build Showcase with Mojarra 2.1.26, deployed on Tomcat 7.0.41, browsed with IE8. Everything worked as expected.
[~hazendaz], can you, please, name just one Showcase example, where it didn't work?
> Richfaces 4.3.4 ajax fails on ie8 packed.js cannot find console.
> ----------------------------------------------------------------
>
> Key: RF-13246
> URL: https://issues.jboss.org/browse/RF-13246
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Reporter: Jeremy Landis
> Assignee: Jiří Štefek
>
> After upgrading to richfaces 4.3.4 using jsf 2.1.26, ajax has stopped working in IE8. I have been able to verify non issue in firefox and IE11. The issue affects specialized ajax calls within a page as well as overall ajax page areas. It further affects extended data grids where it will not allow next page logic to work.
--
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
12 years, 5 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska edited comment on RF-12802 at 10/14/13 4:05 AM:
------------------------------------------------------------
Couple of additional refactorings, we have discussed offline:
* Create interface for method {{advance()}} -
{code}
AdvancedInteractions<T> {
T advanced();
}
{code}
We can document the method more easily - the fragment will implement that interface
* provide a way to set JS strategy in {{arquillian.xml}} - e.g.
{code:xml}
<extension name="richfacesPageFragments"><property name="controlStrategy">interactive</property>
{code}
See ARQGRA-325 comments as well.
* waiting API - put {{withTimeout}} right to the wrapper, so the public API methods do not have call for the actual timeout value
* rename the parameter for setting of the timeout from _timeout_ to something which shows in what time unit it is - e.g. miliseconds
* move fields which hold timeout value to the {{AdvancedInteraction}} classes
* use miliseconds in waiting API instead of seconds as we found them to be more used accros tests
* review exception throwing - throw them where it is necessary, make the method no operation where it is not necessary
* make an attribute from [this|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments...].
* make a pull request with moved repository
* write Javadoc
was (Author: jhuska):
Couple of additional refactorings, we have discussed offline:
* Create interface for method {{advance()}} -
{code}
AdvancedInteractions<T> {
T advanced();
}
{code}
We can document the method more easily - the fragment will implement that interface
* provide a way to set JS strategy in {{arquillian.xml}} - e.g.
{code:xml}
<extension name="richfacesPageFragments"><property name="controlStrategy">interactive</property>
{code}
See ARQGRA-325 comments as well.
* waiting API - put {{withTimeout}} right to the wrapper, so the public API methods do not have call for the actual timeout value
* rename the parameter for setting of the timeout from _timeout_ to something which shows in what time unit it is - e.g. miliseconds
* move fields which hold timeout value to the {{AdvancedInteraction}} classes
* use miliseconds in waiting API instead of seconds as we found them to be more used accros tests
* review exception throwing - throw them where it is necessary, make the method no operation where it is not necessary
* make an attribute from [this|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments...].
* make a pull request with moved repository
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Juraj Húska
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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
12 years, 5 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska updated RF-12802:
-----------------------------
Assignee: Juraj Húska
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Assignee: Juraj Húska
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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
12 years, 5 months
[JBoss JIRA] (RF-12802) Move page fragments from repository qa to richfaces5
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-12802?page=com.atlassian.jira.plugin.s... ]
Juraj Húska edited comment on RF-12802 at 10/14/13 2:26 AM:
------------------------------------------------------------
Couple of additional refactorings, we have discussed offline:
* Create interface for method {{advance()}} -
{code}
AdvancedInteractions<T> {
T advanced();
}
{code}
We can document the method more easily - the fragment will implement that interface
* provide a way to set JS strategy in {{arquillian.xml}} - e.g.
{code:xml}
<extension name="richfacesPageFragments"><property name="controlStrategy">interactive</property>
{code}
See ARQGRA-325 comments as well.
* waiting API - put {{withTimeout}} right to the wrapper, so the public API methods do not have call for the actual timeout value
* rename the parameter for setting of the timeout from _timeout_ to something which shows in what time unit it is - e.g. miliseconds
* move fields which hold timeout value to the {{AdvancedInteraction}} classes
* use miliseconds in waiting API instead of seconds as we found them to be more used accros tests
* review exception throwing - throw them where it is necessary, make the method no operation where it is not necessary
* make an attribute from [this|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments...].
* make a pull request with moved repository
was (Author: jhuska):
Couple of additional refactorings, we have discussed offline:
* Create interface for method {{advance()}} -
{code}
AdvancedInteractions<T> {
T advanced();
}
{code}
We can document the method more easily - the fragment will implement that interface
* provide a way to set JS strategy in {{arquillian.xml}} - e.g.
{code:xml}
<extension name="richfacesPageFragments"><property name="controlStrategy">interactive</property>
{code}
See ARQGRA-325 comments as well.
* waiting API - put {{withTimeout}} right to the wrapper, so the public API methods do not have call for the actual timeout value
* rename the parameter for setting of the timeout from _timeout_ to something which shows in what time unit it is - e.g. miliseconds
* move fields which hold timeout value to the {{AdvancedInteraction}} classes
* use miliseconds in waiting API instead of seconds as we found them to be more used accros tests
* review exception throwing - throw them where it is necessary, make the method no operation where it is not necessary
* make an attribute from [this|https://github.com/richfaces/richfaces-qa/blob/master/page-fragments...].
> Move page fragments from repository qa to richfaces5
> ----------------------------------------------------
>
> Key: RF-12802
> URL: https://issues.jboss.org/browse/RF-12802
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 5.0.0.Alpha1
> Reporter: Pavol Pitonak
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> As discussed on community meeting on Feb 12, we should move page fragments for RichFaces components to richfaces5 repository so that they are distributed with framework.
> We should find out how to prepare them so that they are easy to use for community members. RichFaces QE/dev need to test internals of components, community members will probably test only high-level functionality of components. One possible solution would be to create package "internal" in which there would be page fragments extending those from "public" package. QE team would then use "internal" implementations.
--
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
12 years, 5 months
[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Fab Mars edited comment on RF-13098 at 10/13/13 3:07 PM:
---------------------------------------------------------
I added org.jboss.weld.util.el.ForwardingMethodExpression to /org/richfaces/resource/resource-serialization.properties in my own war (which is itself in an ear).
Nothing changes, I'm puzzled now.
By the way I checked LookAheadObjectInputSteam#loadWhitelist() and the text of the RuntimeException on stream.close is wrong ("Error closing the ResourceBuilder.properties file").
was (Author: fabmars):
I added org.jboss.weld.util.el.ForwardingMethodExpression to /org/richfaces/resource/resource-serialization.properties in my own war (which is itself in an ear).
Nothing changes, I'm puzzled now.
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.4, 5.0.0.Alpha2
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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
12 years, 5 months