5:03 a.m.
I am not sure at what point we plan to support Servlet 3.1, but its reference
implementation Tomcat 8 is quite stable now (8.0.1 was released).
I have tried to deploy showcase on Tomcat 8, but following error is thrown during
deployment:
{code:jivemacro_uid=_13920475018305495|class=_jivemacro_uid_13920475018305495
jive_text_macro jive_macro_code}
SEVERE: Critical error during deployment:
java.lang.NoSuchMethodError:
com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
at com.google.common.cache.LocalCache.<clinit>(LocalCache.java:155)
at
com.google.common.cache.LocalCache$LocalLoadingCache.<init>(LocalCache.java:4871)
at com.google.common.cache.CacheBuilder.build(CacheBuilder.java:806)
at
org.richfaces.resource.ResourceLibraryFactoryImpl.<init>(ResourceLibraryFactoryImpl.java:49)
at org.richfaces.services.DefaultModule.configure(DefaultModule.java:65)
at org.richfaces.services.ServicesFactoryImpl.init(ServicesFactoryImpl.java:49)
at
org.richfaces.services.InitializationListener.createFactory(InitializationListener.java:130)
at
org.richfaces.services.InitializationListener.onStart(InitializationListener.java:68)
at
org.richfaces.services.InitializationListener.processEvent(InitializationListener.java:152)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at
com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187)
at
com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303)
at
org.jboss.weld.environment.servlet.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:282)
at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:691)
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4732)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:976)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1554)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1428)
at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:702)
at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:428)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:615)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:74)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:509)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1015)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:651)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1575)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1533)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
I tried to change guava from the version 13 to the latest one: 16, but than another guava
related error is thrown. Same with guava 15 as it is in WildFly. But it somehow does not
relate to guava, as simple-app with guava 13 works fine on Tomcat 8. Metamer is suffering
from the same issue.
Is there anything else I can do in this matter ? Can I file an issue to support Servlet
3.1 ?
Thanks
Juro
Posted by forums
Original post: https://community.jboss.org/message/856976#856976
7:07 a.m.
This does become a pain point for users as the guava library moves quite rapidly. and
deprecates/removes quickly.
That is fine for user code as I can easily refactor, but if I want to use a new guava
version to get a new features I must occasionally wait for Guava to to be upgraded in a
Richfaces release.
Maybe RF shouldn't depend on Guava or at a minimum shouldn't depend on anything
annotated @Beta as Closables was
(http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...)
Posted by forums
Original post: https://community.jboss.org/message/857179#857179
2:39 p.m.
It would be nice to remove one more dependency.
Guava is now built into huge number of project classes,
so it won't be trivial task. Some analysis of how much classes are
involved.. anyone?
On Tue, Feb 11, 2014 at 7:07 PM, Cody Lerum
<richfaces-dev(a)lists.jboss.org>wrote:
This does become a pain point for users as the guava library moves
quite
rapidly. and deprecates/removes quickly.
That is fine for user code as I can easily refactor, but if I want to use
a new guava version to get a new features I must occasionally wait for
Guava to to be upgraded in a Richfaces release.
Maybe RF shouldn't depend on Guava or at a minimum shouldn't depend on
anything annotated @Beta as Closables was (
http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...
)
Posted by forums
Original post: https://community.jboss.org/message/857179#857179
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
2:55 p.m.
On Wed 12 Feb 2014 12:39:46 PM PST, Lukáš Fryč wrote:
It would be nice to remove one more dependency.
+1. I don't like the idea of dropping it altogether though. Many of
the abstractions it introduces are quite useful and lead to cleaner code.
On Tue, Feb 11, 2014 at 7:07 PM, Cody Lerum
<richfaces-dev(a)lists.jboss.org <mailto:richfaces-dev@lists.jboss.org>>
wrote:
Maybe RF shouldn't depend on Guava or at a minimum shouldn't
depend on anything annotated @Beta as Closables was
(http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...)
+1 for sticking to the stable API.
We could re-explore the idea of shading guava into the richfaces jar
under a different package name. The downside here is it would be easy
to forget about upgrading the library, however this would no longer
effect user applications nor interact with leaky containers.
Brian
3:17 p.m.
Agree, until Java 8 arrives to masses, Guava is very useful.
----
Shading is certainly an option.
----
I was wondering how much of Guava code we could strip by limiting to just
the classes we use directly/transitively.
With a minimal compilation (minimizeJar [1]) results are not convincing:
1437 classes (original guava) -> 919 (minimized guava - limited to only
what we use / use transitively)
Here is a configuration: https://gist.github.com/lfryc/b86d64c2a20843db0ec2
But no one says we do even need to use it minimizeJar. ;-)
[1]
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#minimi...
On Wed, Feb 12, 2014 at 9:55 PM, Brian Leathem <bleathem(a)gmail.com> wrote:
On Wed 12 Feb 2014 12:39:46 PM PST, Lukáš Fryč wrote:
>
> It would be nice to remove one more dependency.
+1. I don't like the idea of dropping it altogether though. Many of
the abstractions it introduces are quite useful and lead to cleaner code.
> On Tue, Feb 11, 2014 at 7:07 PM, Cody Lerum
> <richfaces-dev(a)lists.jboss.org <mailto:richfaces-dev@lists.jboss.org>>
> wrote:
>
> Maybe RF shouldn't depend on Guava or at a minimum shouldn't
> depend on anything annotated @Beta as Closables was
> (
http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...
)
+1 for sticking to the stable API.
We could re-explore the idea of shading guava into the richfaces jar
under a different package name. The downside here is it would be easy
to forget about upgrading the library, however this would no longer
effect user applications nor interact with leaky containers.
Brian
9:56 p.m.
I have created [RF-13548] Clean using of guava dependency across framework - JBoss Issue
Tracker (https://issues.jboss.org/browse/RF-13548) to track cleaning of Guava dependency.
Posted by forums
Original post: https://community.jboss.org/message/857439#857439
8:51 a.m.
There are currently three issues addressing Guava problem:
https://issues.jboss.org/browse/RF-13247
https://issues.jboss.org/browse/RF-13538
https://issues.jboss.org/browse/RF-13548
On Thu, Feb 13, 2014 at 9:56 AM, Juraj Húska <jhuska(a)redhat.com> wrote:
I have created [RF-13548] Clean using of guava dependency across
framework
- JBoss Issue Tracker (https://issues.jboss.org/browse/RF-13548) to track
cleaning of Guava dependency.
Posted by forums
Original post: https://community.jboss.org/message/857439#857439
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
7:35 a.m.
New subject: Guava dependency - to drop or not to drop?
Just for information, there is a list of APIs we use:
richfaces5]$ find -name "*.java" -exec grep "import com.google.common"
{} \; | sort | uniq
{code:jivemacro_uid=_13923165009138769|class=jive_text_macro jive_macro_code
_jivemacro_uid_13923165009138769}
import com.google.common.base.Function;
import com.google.common.base.Joiner;
import com.google.common.base.Objects;
import com.google.common.base.Objects.ToStringHelper;
import com.google.common.base.Optional;
import com.google.common.base.Preconditions;
import com.google.common.base.Predicate;
import com.google.common.base.Predicates;
import com.google.common.base.Splitter;
import com.google.common.base.Strings;
import com.google.common.base.Supplier;
import com.google.common.base.Suppliers;
import com.google.common.cache.CacheBuilder;
import com.google.common.cache.CacheLoader;
import com.google.common.cache.LoadingCache;
import com.google.common.collect.AbstractIterator;
import com.google.common.collect.ArrayListMultimap;
import com.google.common.collect.ClassToInstanceMap;
import com.google.common.collect.Collections2;
import com.google.common.collect.Constraint;
import com.google.common.collect.Constraints;
import com.google.common.collect.ForwardingIterator;
import com.google.common.collect.ForwardingSet;
import com.google.common.collect.HashMultimap;
import com.google.common.collect.ImmutableClassToInstanceMap;
import com.google.common.collect.ImmutableList;
import com.google.common.collect.ImmutableList.Builder;
import com.google.common.collect.ImmutableMap;
import com.google.common.collect.ImmutableMap.Builder;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.ImmutableSet.Builder;
import com.google.common.collect.Iterables;
import com.google.common.collect.Iterators;
import com.google.common.collect.LinkedListMultimap;
import com.google.common.collect.ListMultimap;
import com.google.common.collect.Lists;
import com.google.common.collect.MapMaker;
import com.google.common.collect.Maps;
import com.google.common.collect.Multimap;
import com.google.common.collect.MutableClassToInstanceMap;
import com.google.common.collect.ObjectArrays;
import com.google.common.collect.Ordering;
import com.google.common.collect.Range;
import com.google.common.collect.Ranges;
import com.google.common.collect.SetMultimap;
import com.google.common.collect.Sets;
import com.google.common.collect.UnmodifiableIterator;
import com.google.common.io.ByteStreams;
import com.google.common.io.Closeables;
import com.google.common.io.Files;
import com.google.common.io.InputSupplier;
import com.google.common.io.OutputSupplier;
import com.google.common.primitives.Ints;
import com.google.common.primitives.Primitives;
import com.google.common.util.concurrent.ThreadFactoryBuilder;
{code}
Posted by forums
Original post: https://community.jboss.org/message/857565#857565
7:46 a.m.
New subject: Guava dependency - to drop or not to drop?
Since Pavel asked in JIRA
(https://issues.jboss.org/browse/RF-13247?focusedCommentId=12944199&pa...)
whether we could drop Guava in favor of Java 7, there is an answer:
Code base make use of following APIs:
* functional (Java 8)
* joiners/splitters (none)
* cache builders/loaders (none)
* collections* multimaps (none)
* auto-closeables (Java 7)
* stream / file manipulation (none)
* ...
Posted by forums
Original post: https://community.jboss.org/message/857568#857568
9:12 p.m.
New subject: Guava dependency - to drop or not to drop?
I agree with Cody that Guava is something what final application developer should decide
about.
---
As I said, a re-factoring is not simply addressable at this point,
but I believe we can shade Guava library (even in minimized form) into RichFaces.
It will avoid collisions and ensure stability of API for us.
I'm not afraid we will forget about upgrading - when there is a critical issue in
Guava (such as a bug we track down or security issue), we will be forced to upgrade.
In major (and sometimes minor) revisions we upgrade from time to time.
Additionally it would be good to take the list of interfaces I listed above and make sure
we don't depend on @Beta interfaces.
---
What do you think?
Posted by forums
Original post: https://community.jboss.org/message/857670#857670
9:32 a.m.
New subject: Guava dependency - to drop or not to drop?
Eliminating the @Beta uses will only reduce the issues that users have with regard to
richfaces versions and guava. Shading seems to be most foolproof fix.
As far as version upgrades it would make sense to simply track along with major Wildlfy
release to ensure that you haven't fallen too far behind.
Posted by forums
Original post: https://community.jboss.org/message/857847#857847
11:39 a.m.
New subject: Guava dependency - to drop or not to drop?
Let's go ahead and try shading. We should probably create some high-level package
into which we place our shaded classes. Something like +org.richfaces.shaded.guava+.
We'll use RF-13548 to track this effort.
Note: IIRC the Apache shade plugin caused an issue with productisation. Let's
continue despite this potential problem and deal with it when/if it comes up.
Brian
Posted by forums
Original post: https://community.jboss.org/message/858148#858148
12:11 a.m.
New subject: Guava dependency - to drop or not to drop?
Brian, do you want to implement shading in all versions of RichFaces, i.e. 5.0, 4.5 and
4.3?
Posted by forums
Original post: https://community.jboss.org/message/858223#858223
7:33 a.m.
New subject: Guava dependency - to drop or not to drop?
@Pavel, Marek: do you have any concerns about using maven-shade-plugin to
integrate Guava library into richfaces.jar?
I think the problem we faced in RF 4.3 in WFK was about usage of Shade
Transformers (that we do not use in RF5), but I don't recall the problem
specifically.
----
@Pavol: Shading of Guava in 5.0 applies to 4.5 as well.
I don't think we should back-port it to 4.3, at least not at this point.
7:26 a.m.
It seems it really relates to Guava version. Does the Tomcat
8 itself bundle Guava library ?
It is possible that simpleapp works just fine because it does not require
Guava incidentally (none of its codepaths doesn't hit the problem above).
Note that there are other issues with Guava:
https://issues.jboss.org/browse/RF-13538
Guava proves to be quite unstable API to code against.
That's caused by really poor backward compatibility code management.
On Mon, Feb 10, 2014 at 5:03 PM, Juraj Húska <jhuska(a)redhat.com> wrote:
I am not sure at what point we plan to support Servlet 3.1, but its
reference implementation Tomcat 8 is quite stable now (8.0.1 was released).
I have tried to deploy showcase on Tomcat 8, but following error is thrown
during deployment:
{code:jivemacro_uid=_13920475018305495|class=_jivemacro_uid_13920475018305495
jive_text_macro jive_macro_code}
SEVERE: Critical error during deployment:
java.lang.NoSuchMethodError:
com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
at com.google.common.cache.LocalCache.<clinit>(LocalCache.java:155)
at
com.google.common.cache.LocalCache$LocalLoadingCache.<init>(LocalCache.java:4871)
at com.google.common.cache.CacheBuilder.build(CacheBuilder.java:806)
at
org.richfaces.resource.ResourceLibraryFactoryImpl.<init>(ResourceLibraryFactoryImpl.java:49)
at org.richfaces.services.DefaultModule.configure(DefaultModule.java:65)
at
org.richfaces.services.ServicesFactoryImpl.init(ServicesFactoryImpl.java:49)
at
org.richfaces.services.InitializationListener.createFactory(InitializationListener.java:130)
at
org.richfaces.services.InitializationListener.onStart(InitializationListener.java:68)
at
org.richfaces.services.InitializationListener.processEvent(InitializationListener.java:152)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at
com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187)
at
com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
at
com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303)
at
org.jboss.weld.environment.servlet.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:282)
at
com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:691)
at
com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:253)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4732)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5154)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:976)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:461)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1554)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
at
org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1428)
at
org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.java:702)
at
org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java:428)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:615)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:74)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:509)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1015)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:651)
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1575)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1533)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
I tried to change guava from the version 13 to the latest one: 16, but
than another guava related error is thrown. Same with guava 15 as it is in
WildFly. But it somehow does not relate to guava, as simple-app with guava
13 works fine on Tomcat 8. Metamer is suffering from the same issue.
Is there anything else I can do in this matter ? Can I file an issue to
support Servlet 3.1 ?
Thanks
Juro
Posted by forums
Original post: https://community.jboss.org/message/856976#856976
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
4284
days inactive
4292
days old
14 comments
7 participants
participants (7)
-
Brian Leathem -
Brian Leathem -
Cody Lerum
-
Juraj Húska -
Lukáš Fryč -
Lukáš Fryč
-
Pavol Pitonak