March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3109) CloseReason always null for WebSocket onClose methods

by Frank Hempel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.... ] Frank Hempel commented on WFLY-3109: ------------------------------------ I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)). > CloseReason always null for WebSocket onClose methods > ----------------------------------------------------- > > Key: WFLY-3109 > URL: https://issues.jboss.org/browse/WFLY-3109 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits) > Reporter: Tom Tom > > The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null. > With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side. > Simplified code sample of the endpoint: > @ServerEndpoint(value = "/test", configurator = MyConfigurator.class) > public class MyEndpoint { > // onOpen, onMessage and onError, LOGGER are omitted > @OnClose > public void onClose(Session session, CloseReason reason) { > LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason); > } > } -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3109) CloseReason always null for WebSocket onClose methods

by Frank Hempel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3109?page=com.atlassian.jira.plugin.... ] Frank Hempel edited comment on WFLY-3109 at 3/27/14 6:07 AM: ------------------------------------------------------------- I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the latest Snapshot (build #1043 (26.03.2014 18:41:28)). was (Author: struppimoppi): I would just like to confirm this fact. I also see this "reason-always-null"-behaviour on WildFly 8.0.0.Final as well as the lates Snapshot (build #1043 (26.03.2014 18:41:28)). > CloseReason always null for WebSocket onClose methods > ----------------------------------------------------- > > Key: WFLY-3109 > URL: https://issues.jboss.org/browse/WFLY-3109 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final on Windows 7 Pro (64 bits) with JDK 7.0u51 (64 bits) > Reporter: Tom Tom > > The onClose method of the websocket endpoints does not receive valid CloseReason, it is always null. > With GlassFish 4.0, the CloseReason is not null and correctly reflects the code and message used to close the wensocket from the client side. > Simplified code sample of the endpoint: > @ServerEndpoint(value = "/test", configurator = MyConfigurator.class) > public class MyEndpoint { > // onOpen, onMessage and onError, LOGGER are omitted > @OnClose > public void onClose(Session session, CloseReason reason) { > LOGGER.debug("onClose(sessionId={}, reason={})", session.getId(), reason); > } > } -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3087) Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373)

by Frank Hempel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3087?page=com.atlassian.jira.plugin.... ] Frank Hempel commented on WFLY-3087: ------------------------------------ It still bails out with the same traceback. I used the last snapshot, which is build #1043 (26.03.2014 18:41:28). Undertow is there included in version 1.0.3. But that is no suprise, current master of undertow shows that the code is still the same (https://github.com/undertow-io/undertow/blob/master/websockets-jsr/src/ma...). It probably should better be reported in the undertow tracker. I'm not sure whether you could just move this ticket to the undertow's jira instance or whether it should be opened there separately. > Websocket NullPointerException on io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373) > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3087 > URL: https://issues.jboss.org/browse/WFLY-3087 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: windows server 2008 > Reporter: Admin FlirtyMob > Assignee: Stuart Douglas > Fix For: 8.0.1.Final > > > 2014-03-07 17:10:49,208 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException > at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.handleBinaryMessage(AnnotatedEndpoint.java:373) > at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.access$1100(AnnotatedEndpoint.java:126) > at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:332) > at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler$6.complete(AnnotatedEndpoint.java:329) > at io.undertow.websockets.core.BufferedBinaryMessage.read(BufferedBinaryMessage.java:76) > at io.undertow.websockets.jsr.annotated.AnnotatedEndpoint$AnnotatedEndpointFrameHandler.onBinary(AnnotatedEndpoint.java:329) > at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:24) > at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4] > at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:615) > at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:601) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4] > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4] > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4] > at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4] -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3177) wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly.

by Ravshan Samandarov (JIRA)

Ravshan Samandarov created WFLY-3177: ---------------------------------------- Summary: wrong placement of jipijapa-eclipselink-1.0.1.Final.jar file inside bundle. Eclipselink logger to work properly it should be moved from org/eclipse/persistence/main to org/jipijapa/eclipselink/main and configured in xml file accordingly. Key: WFLY-3177 URL: https://issues.jboss.org/browse/WFLY-3177 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Ravshan Samandarov -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1729) Implement a SASL AuthToken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1729?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1729. ---------------------------- Resolution: Done > Implement a SASL AuthToken > -------------------------- > > Key: JGRP-1729 > URL: https://issues.jboss.org/browse/JGRP-1729 > Project: JGroups > Issue Type: Feature Request > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Labels: 630, security > Fix For: 3.5 > > > Implementing a SASL AuthToken will give us the ability to use whatever SASL mechs are offered by the underlying platform without introducing new dependencies. It would also replace many of the currently provided AuthToken implementations (MD5, X509, Krb5) with a more secure, flexible implementation (e.g. safe from replay attacks) -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED

by Christian Bauer (JIRA)

[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Christian Bauer commented on WFLY-3105: --------------------------------------- Thanks Scott, tested and works now. > Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3105 > URL: https://issues.jboss.org/browse/WFLY-3105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Christian Bauer > Assignee: Scott Marlow > Fix For: 8.0.1.Final > > > https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s... > Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. > Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-102) Messages#getBundle() needs to be privileged

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-102?page=com.atlassian.jira.plu... ] Ivo Studensky commented on JBLOGGING-102: ----------------------------------------- I can't see any fix at [1] [2] [3] [4] [5] [6] [7] [8]. Am I looking at wrong source code? [1] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org... [2] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org... [3] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org... [4] https://github.com/jboss-logging/jboss-logging/blob/3.1/src/main/java/org... [5] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/... [6] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/... [7] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/... [8] https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/... > Messages#getBundle() needs to be privileged > ------------------------------------------- > > Key: JBLOGGING-102 > URL: https://issues.jboss.org/browse/JBLOGGING-102 > Project: JBoss Logging > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.1.4.GA, 3.2.0.Beta1 > Reporter: Ivo Studensky > Assignee: James Perkins > Fix For: 3.1.3.GA, 3.2.0.Beta1 > > > It ({{org.jboss.logging.Messages#getBundle(Class<T> type, Locale locale)}}) calls {{type.getClassLoader()}} which requires privileges when running with Security Manager. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers as modules with no driver

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2655: ----------------------------------------------- James Livingston <jlivings(a)redhat.com> changed the Status of [bug 1043339|https://bugzilla.redhat.com/show_bug.cgi?id=1043339] from NEW to ASSIGNED > Show warning for JDBC drivers as modules with no driver > ------------------------------------------------------- > > Key: WFLY-2655 > URL: https://issues.jboss.org/browse/WFLY-2655 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: James Livingston > Assignee: Jeff Zhang > Fix For: 8.0.1.Final > > > If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers. > When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot the problem. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3168: -------------------------------------- Any chance you installed WF from RPM (or .deb), and there is something screwy in the rpm version? Either way this is not our bug, but should be filed against whoever provides the packages, we don't provided different downloads for Linux and Windows, just the single zip file. > Wrong Mojarra version on Linux > ------------------------------ > > Key: WFLY-3168 > URL: https://issues.jboss.org/browse/WFLY-3168 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.Final > Environment: Linux > Reporter: Thorsten Richter > Assignee: Farah Juma > Labels: jsf, linux, mojarra, viewscoped > > We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work. > So we searched for the root cause and found out, that the Mojarra version was different on Linux. > The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted. > The Windows package of Wildfly doesn't even contain a com folder within modules. > So maybe the whole com folder on Linux is wrong? -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3168) Wrong Mojarra version on Linux

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3168?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3168. ---------------------------------- Resolution: Rejected > Wrong Mojarra version on Linux > ------------------------------ > > Key: WFLY-3168 > URL: https://issues.jboss.org/browse/WFLY-3168 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.Final > Environment: Linux > Reporter: Thorsten Richter > Assignee: Farah Juma > Labels: jsf, linux, mojarra, viewscoped > > We had a bug on Linux that the @ViewScoped annotation didn't work for AJAX requests. We found out, that the Mojarra version is causing the problem. On our Windows development machines everything worked fine, but on the Linux production server @ViewScoped didn't work. > So we searched for the root cause and found out, that the Mojarra version was different on Linux. > The Linux package of Wildfly contains an older version of Mojarra (2.1.7) within the modules/com/sun/jsf-impl folder that needs to be deleted. > The Windows package of Wildfly doesn't even contain a com folder within modules. > So maybe the whole com folder on Linux is wrong? -- 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, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014