Thanks Mike!
First I thought about a solution like You described. But Kito's
solution is much more simple. It gives back the full jsf-api filename
(like "C://jsf-api-1.2_15_Bo2.jar"). So I can control very
easily the Version-no.
I have to deploy to WAS6.1 WAS7 and JBoss6. And now found out that o
You'll have to look at the archives to find the exact code, but in the
past, there has been code used to detect the difference between JSF
1.1 and 1.0, and possibly 1.2.
Use reflection to find a method that only exists in the later versions.
The standalone facelets library for JSF 1.x did this.
O
Thanks Kito,
thats great! Now I can control if really the expected jsf.jar is loaded!
Regards,
Georg
2011/10/27 Kito Mann :
> Hello Georg,
>
> There isn't a standard API for revealing the JSF version, but you can
> reveal the location of the JSF API JAR:
>
> System.out.println("JSF API Location
Hello Georg,
There isn't a standard API for revealing the JSF version, but you can
reveal the location of the JSF API JAR:
System.out.println("JSF API Location: "
+ FacesContext.class.getProtectionDomain().getCodeSource());
This will print out the path to the JAR that contains the FacesContext.
Hallo!
My WebApp needs to use Jsf with the Version 1.2.15B02. In WAS7 I
achieved this by using shared Libraries. Unfortunately often we forget
to switch on these shared libs. In this case the App runs but on later
sites there will be mistakes due to different cashing of Managed
beans.
Therefore I
5 matches
Mail list logo
