[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-10630:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Stuart Douglas)
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Bartosz Baranowski
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JGRP-2241) Bundler using direct memory as buffer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2241:
---------------------------
Fix Version/s: 5.0
(was: 4.0.14)
Moved to 5.0, as the new payload scheme lends itself better to passing a direct byte buffer to the transport.
> Bundler using direct memory as buffer
> -------------------------------------
>
> Key: JGRP-2241
> URL: https://issues.jboss.org/browse/JGRP-2241
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> The current bundler impls use a byte[] array in an output stream as buffer into which messages are written.
> If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate.
> Direct buffers can also be used on the receiver side, investigate.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2777) Guided Decision Table is changing date field value based on the timezone
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2777?page=com.atlassian.jira.plugi... ]
Michael Anstis moved RHPAM-1420 to DROOLS-2777:
-----------------------------------------------
Project: Drools (was: Red Hat Process Automation Manager)
Key: DROOLS-2777 (was: RHPAM-1420)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: Guided Decision Table Editor
(was: Business Central)
QE Status: NEW
> Guided Decision Table is changing date field value based on the timezone
> ------------------------------------------------------------------------
>
> Key: DROOLS-2777
> URL: https://issues.jboss.org/browse/DROOLS-2777
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Labels: drools-tools
>
> If I set a Date Field in Guided Decision Table, then change the timezone, restart the server, log in again, the Date Field has *different* value
> Expected: decision-central should never attempt to change the rules automatically without user's knowledge
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2773) NPE when creating a new KieScanner
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2773?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2773.
---------------------------------
Resolution: Done
Fixed by https://github.com/kiegroup/drools/commit/545832dfa38a1a3b91a20ba2ed8dea4...
> NPE when creating a new KieScanner
> ----------------------------------
>
> Key: DROOLS-2773
> URL: https://issues.jboss.org/browse/DROOLS-2773
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.8.0.Final
> Reporter: Raphael Bowen Giudice
> Assignee: Mario Fusco
>
> When creating a new *KieScanner*, a *NullPointerException* is thrown. Here's the code where the *KieScanner* is created:
> {code:java}
> final KieServices kieServices = KieServices.Factory.get();
> final KieContainer kieContainer = kieServices.newKieContainer(
> kieServices.newReleaseId("mygroup", "rules", "1.0-SNAPSHOT"));
> final KieScanner kieScanner = kieServices.newKieScanner(kieContainer);
> {code}
> The method *indexArtifacts* in the *KieRepositoryScannerImpl* class, tries to index all the Maven artefacts.In my case, the artefact *sun.jdk:jconsole:jdk* cannot be resolved, which causes the *NullPointerException* in the line 399:
> {code:java}
> private Map<ReleaseId, DependencyDescriptor> indexArtifacts() {
> Map<ReleaseId, DependencyDescriptor> depsMap = new HashMap<ReleaseId, DependencyDescriptor>();
> for (DependencyDescriptor dep : artifactResolver.getAllDependecies()) {
> if ( !"test".equals(dep.getScope()) && !"provided".equals(dep.getScope()) && !"system".equals(dep.getScope()) ) {
> Artifact artifact = artifactResolver.resolveArtifact(dep.getReleaseId());
> log.debug( artifact + " resolved to " + artifact.getFile() ); // NPE happens here.
> if (isKJar(artifact.getFile())) {
> depsMap.put(adapt( dep.getReleaseIdWithoutVersion() ), new DependencyDescriptor(artifact));
> }
> } else {
> log.debug("{} does not need to be resolved because in scope {}", dep, dep.getScope());
> }
> }
> return depsMap;
> }
> {code}
> The curious part is that the *sun.jdk:jconsole:jdk* artefact is not declared in any of my projects or dependencies, as far as I could investigate.
> Here's the NPE stack trace:
> {code}
> Caused by: java.lang.NullPointerException: null
> at org.kie.scanner.KieRepositoryScannerImpl.indexArtifacts(KieRepositoryScannerImpl.java:399)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:227)
> at com.test.ServiceConfoguration.kieContainer(ServiceConfoguration.java:84)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2.CGLIB$kieContainer$2(<generated>)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2$$FastClassBySpringCGLIB$$f73690dd.invoke(<generated>)
> at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
> at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:356)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2.kieContainer(<generated>)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
> ... 19 common frames omitted
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months