[JBoss JIRA] Created: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
5:11 p.m.
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into
domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Environment: Sun Java System Application Server 9.1 (build b58g-fcs)
Richfaces 3.1.2
Reporter: John Leed
Assignee: Tsikhon Kuprevich
Fix For: 3.2.1
When the Richfaces 3.1.2 libs are put into a domains lib folder under SJSAS 9.1, the Admin
web application breaks.
I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s)."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:20 p.m.
New subject: [JBoss JIRA] Updated: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
John Leed updated RF-5212:
--------------------------
Environment:
Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
was:
Sun Java System Application Server 9.1 (build b58g-fcs)
Richfaces 3.1.2
Affects Version/s: 3.2.2
Description:
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the Admin
web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary fix
as it increases the time and size of the build, which is a pain during development.
was:
When the Richfaces 3.1.2 libs are put into a domains lib folder under SJSAS 9.1, the Admin
web application breaks.
I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s)."
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Tsikhon Kuprevich
Fix For: 3.2.1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:47 a.m.
New subject: [JBoss JIRA] Updated: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Nick Belaevski updated RF-5212:
-------------------------------
Fix Version/s: Future
(was: 3.2.1)
Assignee: Nick Belaevski (was: Tsikhon Kuprevich)
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Nick Belaevski
Fix For: Future
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:59 p.m.
New subject: [JBoss JIRA] Commented: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
John Leed commented on RF-5212:
-------------------------------
Workaround: remove these entries from richfaces-impl-XXX.jar/META-INF/faces-config.xml and
add them to the war's faces-config.xml:
<application>
<state-manager>org.ajax4jsf.application.AjaxStateManager</state-manager>
</application>
<component>
<component-type>javax.faces.ViewRoot</component-type>
<component-class>org.ajax4jsf.component.AjaxViewRoot</component-class>
<component-extension>
<component-family>javax.faces.ViewRoot</component-family>
</component-extension>
</component>
<render-kit>
<renderer>
<description>
override the viewroot
</description>
<component-family>javax.faces.ViewRoot</component-family>
<renderer-type>javax.faces.ViewRoot</renderer-type>
<renderer-class>org.ajax4jsf.renderkit.AjaxViewRootRenderer</renderer-class>
</renderer>
</render-kit>
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Nick Belaevski
Fix For: Future
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:31 a.m.
New subject: [JBoss JIRA] Updated: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Nick Belaevski updated RF-5212:
-------------------------------
Component/s: third-party
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Nick Belaevski
Fix For: Future
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:10 a.m.
New subject: [JBoss JIRA] Updated: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Nick Belaevski updated RF-5212:
-------------------------------
Fix Version/s: 3.3.2.CR1
(was: Future)
Assignee: Alexander Smirnov (was: Nick Belaevski)
Priority: Minor (was: Major)
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Alexander Smirnov
Priority: Minor
Fix For: 3.3.2.CR1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:29 a.m.
New subject: [JBoss JIRA] Commented: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Alexander Smirnov commented on RF-5212:
---------------------------------------
RichFaces library supposed to use riichfaces-api.jar only as a shared library. Other parts
( richfaces-impl and richfaces-ui ) could not be shared between web applications because
they are contains application-specific configuration and, probably, could have static
fields that require a separate class loader.
The other problem is facelets tag libraries that could be read from WEB-INF/lib folder
only.
John Leed workaround could work, richfaces-impl.jar does not contain any static fields
that requires a separate classloader but I can say nothing about richfaces-ui.jar.
Changes in the whole project to allow libraries to be shared between applications requires
significant redesign and can non be done for 3.x releases. Ungoing RichFaces 4.0/JSF 2.0
have some improvements that allows them to be shared at the application level.
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Alexander Smirnov
Priority: Minor
Fix For: 3.3.2.CR1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:29 a.m.
New subject: [JBoss JIRA] Resolved: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Alexander Smirnov resolved RF-5212.
-----------------------------------
Resolution: Won't Fix
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Alexander Smirnov
Priority: Minor
Fix For: 3.3.2.CR1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:07 a.m.
New subject: [JBoss JIRA] Closed: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Tsikhon Kuprevich closed RF-5212.
---------------------------------
Assignee: Tsikhon Kuprevich (was: Alexander Smirnov)
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Tsikhon Kuprevich
Priority: Minor
Fix For: 3.3.2.CR1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:32 p.m.
New subject: [JBoss JIRA] Reopened: (RF-5212) CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the libs are put into domain1/lib folder
[
https://jira.jboss.org/jira/browse/RF-5212?page=com.atlassian.jira.plugin...
]
Dmytro Lisnichenko reopened RF-5212:
------------------------------------
CLONE -Richfaces 3.2.2SR1 breaks SJSAS 9.2_01 Admin web-app, when the
libs are put into domain1/lib folder
----------------------------------------------------------------------------------------------------------
Key: RF-5212
URL: https://jira.jboss.org/jira/browse/RF-5212
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: third-party
Affects Versions: 3.2.2
Environment: Sun Java System Application Server 9.2_01
Richfaces 3.2.2SR1
Reporter: John Leed
Assignee: Tsikhon Kuprevich
Priority: Minor
Fix For: 3.3.2.CR1
When the Richfaces 3.2.2 libs are put into a domains lib folder under SJSAS 9.2, the
Admin web application breaks.
This issue clones issue 1255:
"I filed a bug report on glassfish
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3626 , here's what they had to
say about this:
"In order to understand what is happening you have to know a little bit about how
JSF configures itself. It looks for faces-config.xml files in the classpath to
see if should add new jsf extensions (such as a new ViewHandler) to help it
process jsf pages. JSF does NOT do anything to ensure that a new component
(i.e. ViewHanler) doesn't break other custom jsf extensions. It is unfortunate
that these extensions can't be restricted to a subset of URLs, or be guarenteed
to behave well.
In this case, Ajax4JSF does not behave well. It both of your stack traces it
appears Ajax4JSF is not doing the right thing. In the first, it is not handling
the rendering of the page and has either changed the viewId or done something
else to cause the default viewHandler to also not handle it (it appears it is
redispatching recursively b/c of this). In the 2nd example, it is attempting to
handle a JSFTemplating page instead of delegating to JSFTemplating -- it is
unable to do so and fails.
Ajax4JSF could fix both of these problems -- I cannot. Based on these stack
traces, I would strongly suggest that you not include Ajax4JSF in a shared lib
area as it will effect ALL JSF applications, not just the ones you want it to
effect. Instead place the Ajax4JSF jar files in the WEB-INF/lib of your
application(s).""
We have no other libraries that cannot be shared in the domain lib folder. Putting the RF
jars into the application lib is causing a security permission failure. The permissions
problem was resolvable when the jars were in the domain lib folder by changing the
system.policy file.
IMHO, requiring that the libraries be packaged with the app should only be a temporary
fix as it increases the time and size of the build, which is a pain during development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5259
days inactive
5692
days old
richfaces-issues@lists.jboss.org
9 comments
5 participants
participants (5)
-
Alexander Smirnov (JIRA) -
Dmytro Lisnichenko (JIRA)
-
John Leed (JIRA)
-
Nick Belaevski (JIRA)
-
Tsikhon Kuprevich (JIRA)