Closed GoogleCodeExporter closed 9 years ago
Could you tell us more about the deployment package? Is PrettyFaces located in
the EAR lib directory or in the WAR archive? This would be very interesting to
know, because someone on the forum reported similar issues caused by uncommon
EAR packaging:
http://ocpsoft.com/support/topic/javalangclasscastexception-cannot-be-cast-to-co
mocpsoftprettyfacesrewrite
Original comment by chkalt
on 20 Jul 2010 at 3:17
Sorry, ignore my last comment. I think I found the problem. The
PrettyConfigListener is declared in the web-fragment.xml of the PrettyFaces JSF
1.2 module while the listener itself is contained only in the JSF 2.0 module.
http://code.google.com/p/prettyfaces/source/browse/prettyfaces/trunk/impl-jsf12/
src/main/resources/META-INF/web-fragment.xml
@Lincoln: I think we can remove the listener from the web-fragment.xml of the
JSF 1.2 module, correct?
Original comment by chkalt
on 20 Jul 2010 at 3:33
If you need a quick workaround, just create a class named
com.ocpsoft.pretty.faces.config.PrettyConfigListener implementing
ServletRequestListener. This class doesn't need to do anything, because
PrettyConfigListener is only responsible for JSF 2.0 specific things (project
stages). This should fix this problem until we release the next PrettyFaces
version.
Original comment by chkalt
on 20 Jul 2010 at 3:46
In the meanwhile, I switched back to latest 1.x.x Version.
But thanks for the quick help and this excellent project!
By the way:
I found a prettyfaces-core-3.0.x.jar package in the download repository.
Is this package (going to be) needed?
Original comment by alex.ker...@gmail.com
on 20 Jul 2010 at 6:49
No, you won't need the core package. It is automatically included in the
different JSF version specific packages and is therefore more or less a
byproduct of the build process. :-)
Original comment by chkalt
on 21 Jul 2010 at 5:39
Fixed in r360
Original comment by chkalt
on 21 Jul 2010 at 6:01
web-fragment.xml's are only used in a servlet 3.0 environment which is probably
not in use when using JSF 1.2 (most people use servlet 2.5 there).
In servlet < 3.0 the listeners and filters should be declared in the web.xml
file.
Original comment by dominik....@gmail.com
on 21 Jul 2010 at 8:59
Thank you for the clarification. But I think its OK for us to include the
web-fragment.xml in the JSF 1.2 bundle. Some people (like for example
alex.kerner.24) seem to use JSF 1.2 in a Servlet 3.0 environment (JBossAS 6.0).
In this case the presence of the web-fragment.xml file simplifies the setup of
PrettyFaces. What do you think?
Original comment by chkalt
on 21 Jul 2010 at 10:24
@chkalt: yes, it should reside in the jar, but we should note (in the
documentation) that without servlet 3.0 the user manually has to create the
listener in web.xml and/or in the init method of the filter check if the
listener is loaded and print a warning if not.
Original comment by dominik....@gmail.com
on 21 Jul 2010 at 11:02
So this problem should not occur if I use JBoss5?
Are there any other known problems using JSF1.2 with JBoss6?
Original comment by alex.ker...@gmail.com
on 21 Jul 2010 at 12:43
It should not appear if you use JBoss 5 as its not a JavaEE6 container.
The question is, why you are using JSF 1.2 in a JavaEE6 Environment where JSF 2
is standard (JBoss AS6)?
as for chkalt's answer:
"No, you won't need the core package. It is automatically included in the
different JSF version specific packages and is therefore more or less a
byproduct of the build process. :-)"
This is only true, if you build your project using maven.
If you manually copy together the jars (like its done with eclipse/netbeans),
you also have to include the core.jar
Original comment by dominik....@gmail.com
on 21 Jul 2010 at 12:51
I don't believe that we should remove the entry from web-fragment.xml. The real
solution is to include the listener in the JSF1.2 version of PrettyFaces, this
can be done by upgrading to Servlet 3.0 dep in core and moving the listener
there.
Thoughts?
Original comment by lincolnb...@gmail.com
on 21 Jul 2010 at 8:59
I wouldn't require an upgrade to servlet 3 for jsf 1.2. Simply let the people
manually define it in the web.xml file if they are in a pre servlet 3.0
environment.
Original comment by dominik....@gmail.com
on 21 Jul 2010 at 9:34
@lincoln: But the PrettyConfigListener implements a JSF 2.0 specific feature
(reloading of PrettyFaces configuration on every request when the project stage
is != Production). So I think it should be paced in the JSF 2.0 module.
Original comment by chkalt
on 22 Jul 2010 at 3:37
Woops, @christian, you're right, my bad. I forgot that small part ;)
@dominik, since web-fragment.xml is not used pre-servlet 3.0, including it
doesn't force people to upgrade to servlet 3 :) they just have to define
everything in web.xml like you said, so yes.
Original comment by lincolnb...@gmail.com
on 23 Jul 2010 at 3:48
Okay! So we all agree that r360 fixes the problem and the issue can remain in
'Fixed' status?
Original comment by chkalt
on 23 Jul 2010 at 5:39
Yes :)
Original comment by lincolnb...@gmail.com
on 24 Jul 2010 at 3:14
Original issue reported on code.google.com by
alex.ker...@gmail.com
on 20 Jul 2010 at 10:48