[JBoss JIRA] (WFLY-3529) UT000010: Session not found
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3529:
--------------------------------------
Fixed in Undertow 1.2.0.Beta10.
Note that with the example there is still a small chance that you can get this exception, as the redirect is send before session invalidation happens. This means the browser can request the next page and get hold of the soon to be invalidated session before the invalidation happens, however this is unlikely in practice.
> UT000010: Session not found
> ----------------------------
>
> Key: WFLY-3529
> URL: https://issues.jboss.org/browse/WFLY-3529
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Environment: Wildfly 8.1.0.Final ,
> Reporter: Youssef BIKHCHICHE
> Assignee: Stuart Douglas
> Attachments: WFLY-3529.tar.gz, WFLY-3529.war
>
>
> After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly.
> ERREOR code :
> 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 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: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144)
> at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86)
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402)
> ======================================================
> this issue happens after a http session invalidate action and it' not a regular problems.
> Best regards,
> Youssef
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (DROOLS-729) Android Support
by Mark Kedzierski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Kedzierski updated DROOLS-729:
-----------------------------------
Description:
I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
code:
http://www.github.com/kedzie/drools-android
http://www.github.com/kedzie/drools-android-sample
Features:
-Dex classloaders for all generated classes
-Roboguice integration for injecting knowledge bases from precompiled packages
-Maven plugin which pre-compiles rule packages
Issues:
-Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
-using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
-multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
was:
I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
code:
http://www.github.com/kedzie/drools-android
http://www.github.com/kedzie/drools-android-sample
Features:
-Dex classloaders for all generated classes
-Roboguice integration for injecting knowledge bases from precompiled packages
-Maven plugin which pre-compiles rule packages
Issues:
-Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system
-Haven't tested drools-compiler on android platform
I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> http://www.github.com/kedzie/drools-android-sample
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
> -using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
> -multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (DROOLS-729) Android Support
by Mark Kedzierski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Kedzierski updated DROOLS-729:
-----------------------------------
Affects Version/s: 6.3.0.Final
(was: 6.0.1.Final)
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> http://www.github.com/kedzie/drools-android-sample
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system
> -Haven't tested drools-compiler on android platform
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4405?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4405:
------------------------------------
Assignee: Farah Juma (was: Stuart Douglas)
> NPE in AstValue.setValue()
> --------------------------
>
> Key: WFLY-4405
> URL: https://issues.jboss.org/browse/WFLY-4405
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: MacOS X, RHEL6
> Reporter: Christer Bernérus
> Assignee: Farah Juma
>
> When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue().
> The code where this happens is in javax.el-3.0.1-b05.jar and looks like this:
> {code:title=AstValue.java|borderStyle=solid}
> /* Note by kchung 10/2013
> * The spec does not say if the value should be cocerced to the target
> * type before setting the value to the target. The conversion is kept
> * here to be backward compatible.
> */
> ctx.setPropertyResolved(false);
> Class<?> targetType = elResolver.getType(ctx, t.base, property);
> if (ctx.isPropertyResolved()) {
> ctx.setPropertyResolved(false);
> Object targetValue = elResolver.convertToType(ctx, value, targetType);
> if (ctx.isPropertyResolved()) {
> value = targetValue;
> } else {
> if (value != null || targetType.isPrimitive()) {
> value = ELSupport.coerceToType(value, targetType);
> }
> }
> }
> {code}
> From my debugging session, I have seen that the code in
> {{elResolver.getType()}} may return null, which happens to me,
> but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE.
> Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4405?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-4405:
---------------------------------
Component/s: (was: CDI / Weld)
> NPE in AstValue.setValue()
> --------------------------
>
> Key: WFLY-4405
> URL: https://issues.jboss.org/browse/WFLY-4405
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: MacOS X, RHEL6
> Reporter: Christer Bernérus
> Assignee: Stuart Douglas
>
> When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue().
> The code where this happens is in javax.el-3.0.1-b05.jar and looks like this:
> {code:title=AstValue.java|borderStyle=solid}
> /* Note by kchung 10/2013
> * The spec does not say if the value should be cocerced to the target
> * type before setting the value to the target. The conversion is kept
> * here to be backward compatible.
> */
> ctx.setPropertyResolved(false);
> Class<?> targetType = elResolver.getType(ctx, t.base, property);
> if (ctx.isPropertyResolved()) {
> ctx.setPropertyResolved(false);
> Object targetValue = elResolver.convertToType(ctx, value, targetType);
> if (ctx.isPropertyResolved()) {
> value = targetValue;
> } else {
> if (value != null || targetType.isPrimitive()) {
> value = ELSupport.coerceToType(value, targetType);
> }
> }
> }
> {code}
> From my debugging session, I have seen that the code in
> {{elResolver.getType()}} may return null, which happens to me,
> but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE.
> Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging
by Arsalan Masood (JIRA)
[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ]
Arsalan Masood commented on WFCORE-478:
---------------------------------------
Thanks James!
> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
> Key: WFCORE-478
> URL: https://issues.jboss.org/browse/WFCORE-478
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> Add the following log4j.properties file to a deployment and try to log.
> {code}
> # Root logger option
> log4j.rootLogger=INFO, stdout
> # Direct log messages to stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFCORE-488) Failures of undeploy of a partially failed deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-488?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-488:
---------------------------------------
Assignee: Brian Stansberry (was: Alexey Loubyansky)
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFCORE-488
> URL: https://issues.jboss.org/browse/WFCORE-488
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months