wildfly-8

I am trying to run my application on WildFly8.2, which was build by using Jboss 5.1.I migrated my entire application and able to see the login page. But while navigating to JSF pages, it is throwing the below exception. My old application is build on JSF 1.2 2015-07-15 14:49:02,108 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Initializing Mojarra 2.2.8-jbossorg-1 20140822-1131 for context '/booking' 2015-07-15 14:49:03,303 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Registered web context: /booking 2015-07-15 14:49:03,402 INFO

I have wildfly 8.1 server running. I have my own SessionManager implementing io.undertow.server.session.SessionManager. And i want to configure the system to use my session manager. Where and how should i configure/add new settings for my session manager? public class StartupBeanExtension implements Extension, ServletExtension { @Override public void handleDeployment(DeploymentInfo deployment, ServletContext context) { boolean sessionPersistenceEnabled = Boolean.parseBoolean(BeanUtils.getBean(PropertyResolver.class).getValue("UAM.SessionPersistenceEnabled")); if (sessionPersistenceEnabled) {

I am working on migrating a project from (JSF 1.2, Richfaces 3.3.4 running on JBoss 4.2.3) to (JSF 2.2, Richfaces 4.5 running on Wildfly 8.1.0). After partially migrating some views I found that the performance of the application using JSF 2 is terrible. I noticed this issue when an ajax request is sent, JSF 2 is rendering the whole view although the render attribute is pointing to one outputText Example (Can be downloaded from HERE ) In my example I will use the same code sample for both JSF 1.2 and 2.2. Afterwards I will click on the ajax button multiple times and measure the response time

I'm using Wildfly 8.2 and fire a series of DB requests when a certain web page is opened. All queries are invoked thru JPA Criteria API, return results as expected - and - none of them delivers a warning, error or exception. It all runs in Parallel Plesk. Now, I noticed that within 2 to 3 days the following error appears and the site becomes unresponsive. I restart and I wait approx another 3 days till it happens again (depending on the number of requests I have). I checked the tcpsndbuf on my linux server and I noticed it is constantly at max. Unless I restart Wildfly. Apparently it fails to

How can i run wildfly 8.2.1 in port 80? I can run wildfly in different ports by changing the offset as below. <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:100}"> But unable to run in port 80. Offset adds that value to all ports. So if you had http set to the default port 8080, an offset of 100 would set it to 8180. You want to set the socket for http. <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> <socket-binding name="http" port="${jboss

What is the WildFly (8.2) way to work with randomly salted passwords stored in a database? Is an implementation of org.jboss.crypto.digest.DigestCallback (in the password validation process) meant to have access to the salt part from the database? Or should I simply hash and salt passwords by my self before handing them over to the login method of HttpServletRequest ? It looks to me like the 'WildFly way' to deal with passwords is to do what most containers do and deliver a non-secure solution out-of-the-box. I don't know why, but every standard JDBC realm implementation I've seen so far just

Where does application configuration belong in modern Java EE applications? What best practice(s) recommendations do people have? By application configuration, I mean settings like connectivity settings to services on other boxes, including external ones (e.g. Twitter and our internal Cassandra servers...for things such as hostnames, credentials, retry attempts) as well as those relating business logic (things that one might be tempted to store as constants in classes, e.g. days for something to expire, etc). Assumptions: We are deploying to a Java EE 7 server (Wildfly 8.1) using a single EAR

What is the main difference between security-domain and security-realm in WildFly? standalone.xml <security-domain name="foo"> <authentication> <login-module code="..." flag="..."> </login-module> </authentication> </security-domain> and <security-realm name="foo"> <authentication> <local default-user="..." allowed-users="..." skip-group-loading="..."/> <properties path="..." relative-to="..."/> </authentication> <authorization> <properties path="..." relative-to="..."/> </authorization> </security-realm> Answer updated (2018-06-08) to reflect WildFly Elytron naming. WildFly Elytron is a new