It depends. This is true for resources accessed via EL #{resource} (which I do
not recommend btw because it's a HUGE performance hog - better use restful
resources [1]). For facelets this only got fixed in JSF-2.2. In JSF-2.0 and 2.1
you still need the ResourceResolver to load facelets from a ja
On 27 Feb 2014, Mark Struberg wrote:
> JSF by default loads the resources from the local WAR classpath only. But you
> can easily write your own ResourceResolver which picks the stuff from the
> ClassPath as well.
>
> An example can be found here:
> http://ocpsoft.org/opensource/create-common-f
On 27 Feb 2014, Simon Lessard wrote:
> From a pure JSF point of view, you could also add a
> WEB-INF/faces-config.xml file in your project that redefine all OmniFaces
> artifact that are annotated. It's a super poor man solution/ugly hack as
> you might have to alter the file with every OmniFaces
JSF by default loads the resources from the local WAR classpath only. But you
can easily write your own ResourceResolver which picks the stuff from the
ClassPath as well.
An example can be found here:
http://ocpsoft.org/opensource/create-common-facelets-jar/
See CustomResourceResolver.
LieGr
Hi,
>From a pure JSF point of view, you could also add a
WEB-INF/faces-config.xml file in your project that redefine all OmniFaces
artifact that are annotated. It's a super poor man solution/ugly hack as
you might have to alter the file with every OmniFaces releases, but would
allow you to have th
2014-02-27 17:26 GMT+01:00 Martin Hoeller :
> On 27 Feb 2014, Antonio Petrelli wrote:
>
> > 2014-02-27 17:14 GMT+01:00 Martin Hoeller :
> >
> > > On 27 Feb 2014, Antonio Petrelli wrote:
> > >
> > > > 2014-02-27 17:05 GMT+01:00 Martin Hoeller :
> > > >
> > > > > I have another concrete example with
On 27 Feb 2014, Antonio Petrelli wrote:
> 2014-02-27 17:14 GMT+01:00 Martin Hoeller :
>
> > On 27 Feb 2014, Antonio Petrelli wrote:
> >
> > > 2014-02-27 17:05 GMT+01:00 Martin Hoeller :
> > >
> > > > I have another concrete example with a single WAR where OmniFaces is a
> > > > dependency by the
On 27 Feb 2014, Antonio Petrelli wrote:
> 2014-02-27 17:05 GMT+01:00 Martin Hoeller :
>
> > I have another concrete example with a single WAR where OmniFaces is a
> > dependency by the WAR and by some EJB JAR, both contained in the EAR. The
> > OmniFaces JAR goes in the EARs lib folder and thus O
2014-02-27 17:05 GMT+01:00 Martin Hoeller :
> I have another concrete example with a single WAR where OmniFaces is a
> dependency by the WAR and by some EJB JAR, both contained in the EAR. The
> OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist not
> fully usable without workarounds
Hi Simon!
Thanks for your help...
On 27 Feb 2014, Simon Lessard wrote:
> Hi Martin,
>
> Your definition of the skinny WAR is very slightly off and that may or not
> solve your issue. A skinny WAR is not necessarily a WAR from which *all*
> WEB-INF/lib was stripped, but rather one where all of i
Hi Martin,
Your definition of the skinny WAR is very slightly off and that may or not
solve your issue. A skinny WAR is not necessarily a WAR from which *all*
WEB-INF/lib was stripped, but rather one where all of its dependencies that
are shared by another module in the EAR gets stripped. For exam
Hi all!
Most webapplication developers will probably know the concept of skinny
WARs which is described here [0].
When I have a skinny WAR in an EAR everthing from WAR!WEB-INF/lib is
excluded and goes into the lib-folder of the EAR. Thus, it is in the WARs
classpath.
However, when I use JSF comp
12 matches
Mail list logo
