Hi!
I found the problem.
I requested the to-be-decorated application within my constructor
which failed as with an JSF 1.1. compiled class the FacesContext is
required to find the JSF 1.2 default application implementation.
JSF 1.2 will then dispatch the new methods to the default
Hello Mario,
Comments inline.
On 9/6/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I found the problem.
I requested the to-be-decorated application within my constructor
which failed as with an JSF 1.1. compiled class the FacesContext is
required to find the JSF 1.2 default
Hi Simon!
I guess you could use a ServletContextListener to extract the default
factory from FactoryFinder and then set your own instance passing it
the default implementation, but that would work only if JSF's own
ServletContextListener is executed before, and I'm not aware of the
listener
Hi!
Is the JSF 1.2 API backward compatible?
An application developed with the JSF 1.2 API should run on 1.1 as long
as no 1.2 specific stuff will be used, no?
I ask as I had a UOE in orchestra which seems happened after I override
the ApplicationFactory (and the Application) but still use JSF
JSF
1.2API, I guess the application should run on a JSF
1.1 server.
Regards,
~ Simon
On 9/5/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Is the JSF 1.2 API backward compatible?
An application developed with the JSF 1.2 API should run on 1.1 as long
as no 1.2 specific stuff
Hi!
It's the opposite, as for any backward compatible system. It means
that you can, theoretically, run a JSF 1.1 application on a 1.2 system.
I haven't looked at it in very detail, but it seems if you provide your
own javax.faces.application.Application compiled with JSF1.1 the method
Hello Mario,
On 9/5/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
It's the opposite, as for any backward compatible system. It means
that you can, theoretically, run a JSF 1.1 application on a 1.2 system.
I haven't looked at it in very detail, but it seems if you provide your
own
Hi!
This is, indeed, a compatibility issue. However, I assume it's caused
because you did not use the decorator pattern when you applied your
custom Application implementation, so now you're inheriting from the
default implementation method behavior, which is to throw an