[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed
by Richard Bourner (JIRA)
[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ]
Richard Bourner commented on DROOLS-281:
----------------------------------------
Additional information: it seems like the problem starts occuring for Beta3.
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
> Key: DROOLS-281
> URL: https://issues.jboss.org/browse/DROOLS-281
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR4
> Reporter: Richard Bourner
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2214) LDAP security realm needs to have configurable timeouts
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2214:
----------------------------------------
This actually raises an interesting point to also consider - if we can detect that the first server was not used maybe for a short period of time we should re-order the server list to give a higher priority to the server we know does exist.
As authentication also establishes a connection to the server to verify the password it would be beneficial to lower the priority of the missing server.
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
> Key: WFLY-2214
> URL: https://issues.jboss.org/browse/WFLY-2214
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Beta1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
> result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
> String url = config.require(URL).asString();
> result.put(Context.PROVIDER_URL,url);
> + result.put("com.sun.jndi.ldap.connect.timeout", "500");
> return result;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2157) JSF ViewExpiredException without cookies.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2157.
----------------------------------
Fix Version/s: 8.0.0.Beta1
Resolution: Done
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
> Key: WFLY-2157
> URL: https://issues.jboss.org/browse/WFLY-2157
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 8.0.0.Alpha4
> Reporter: Marek Schmidt
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
> Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> ... 29 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2118) PersistenceException breaks default error page
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-2118:
----------------------------------
I was saying local only stack traces feature works as expected, however it can be confusing, so we should wait for more feedback after the beta to decide if we want to keep it enabled by default.
After thinking about it a bit more however I think we should probably have this disabled by default, so I have re-opened.
> PersistenceException breaks default error page
> ----------------------------------------------
>
> Key: WFLY-2118
> URL: https://issues.jboss.org/browse/WFLY-2118
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> ... 68 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2214) LDAP security realm needs to have configurable timeouts
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2214:
-----------------------------------
Fix Version/s: 8.0.0.Beta1
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
> Key: WFLY-2214
> URL: https://issues.jboss.org/browse/WFLY-2214
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Beta1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
> result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
> String url = config.require(URL).asString();
> result.put(Context.PROVIDER_URL,url);
> + result.put("com.sun.jndi.ldap.connect.timeout", "500");
> return result;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (WFLY-2214) LDAP security realm needs to have configurable timeouts
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-2214:
--------------------------------------
Assignee: Darran Lofthouse (was: Brian Stansberry)
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
> Key: WFLY-2214
> URL: https://issues.jboss.org/browse/WFLY-2214
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
> result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
> String url = config.require(URL).asString();
> result.put(Context.PROVIDER_URL,url);
> + result.put("com.sun.jndi.ldap.connect.timeout", "500");
> return result;
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months