ClassNotFoundException: com.ocpsoft.pretty.faces.config.PrettyConfigListener

[GoogleCodeExporter]

Switching from Version: 1.x.x
Switching to Version: 3.0.1
JSF Version: 1.2
App. Container: JBoss 6.0.0

After switching to PrettyFaces 3.0.1 release, following error occurs while 
deploying EAR-file:

ERROR Error configuring application listener of class 
com.ocpsoft.pretty.faces.config.PrettyConfigListener: 
java.lang.ClassNotFoundException: 
com.ocpsoft.pretty.faces.config.PrettyConfigListener
    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
...

Original issue reported on code.google.com by alex.ker...@gmail.com on 20 Jul 2010 at 10:48

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Fixed in r360

Original comment by chkalt on 21 Jul 2010 at 6:01

• Changed state: Fixed

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

@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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

@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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Yes :)

Original comment by lincolnb...@gmail.com on 24 Jul 2010 at 3:14