[JBoss JIRA] (JBWEB-270) Exception in JBoss with SSO
by Rajesh Sinha (JIRA)
Rajesh Sinha created JBWEB-270:
----------------------------------
Summary: Exception in JBoss with SSO
Key: JBWEB-270
URL: https://issues.jboss.org/browse/JBWEB-270
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Rajesh Sinha
Assignee: Remy Maucherat
Hi,
Below mentioned is a stack trace of the exception which i am getting while accessing a particular JSP page through a SSO(Single Sign On) enabled server. Surprisingly it works completely fine when i switch SSO off.Attached is the JSP which i am referring to.
ERROR - [] [ajp-10.248.0.101-9009-8] - Cannot append null value
java.lang.NullPointerException
at org.apache.coyote.ajp.AjpMessage.appendString(AjpMessage.java:242)
at org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:178)
at org.apache.coyote.ajp.AjpProcessor.prepareResponse(AjpProcessor.java:980)
at org.apache.coyote.ajp.AjpProcessor.action(AjpProcessor.java:494)
at org.apache.coyote.Response.action(Response.java:186)
at org.apache.coyote.Response.sendHeaders(Response.java:386)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:333)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:314)
at org.apache.catalina.connector.Response.flushBuffer(Response.java:557)
at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:344)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
at java.lang.Thread.run(Thread.java:662)
--
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
13 years, 2 months
[JBoss JIRA] (JBWEB-149) Occassional NullPointerException when using the AJP Connector
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-149?page=com.atlassian.jira.plugin.... ]
SBS JIRA Integration updated JBWEB-149:
---------------------------------------
Forum Reference: https://community.jboss.org/message/809750#809750
> Occassional NullPointerException when using the AJP Connector
> --------------------------------------------------------------
>
> Key: JBWEB-149
> URL: https://issues.jboss.org/browse/JBWEB-149
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Reporter: Samuel Mendenhall
> Assignee: Remy Maucherat
>
> ERROR 2009-04-30 10:54:14,547 [ajp-xxxxxxxxxxxxxxxx%2F10.230.10.131-22803-2][][] org.apache.coyote.ajp.AjpMessage 'Cannot append null value'
> java.lang.NullPointerException
> at org.apache.coyote.ajp.AjpMessage.appendString(AjpMessage.java:242)
> at org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:178)
> at org.apache.coyote.ajp.AjpProcessor.prepareResponse(AjpProcessor.java:961)
> at org.apache.coyote.ajp.AjpProcessor.action(AjpProcessor.java:495)
> at org.apache.coyote.Response.action(Response.java:183)
> at org.apache.coyote.Response.sendHeaders(Response.java:379)
> at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
> at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
> at org.apache.catalina.connector.Response.finishResponse(Response.java:486)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:257)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
> at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:619)
> The fix Jean-Frederic highlighted being:
> src/share/classes/org/apache/coyote/ajp/AjpProcessor.java
> responseHeaderMessage.appendInt(numHeaders);
> for (int i = 0; i < numHeaders; i++) {
> MessageBytes hN = headers.getName(i);
> + if (hN == null || hN.toString() == null)
> + continue;
> int hC = Constants.getResponseAjpIndex(hN.toString());
> if (hC > 0) {
> responseHeaderMessage.appendInt(hC);
> +++
> Which, after using a patched jar, the customer has not seen the NPE since.
--
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
13 years, 2 months
[JBoss JIRA] (JGRP-1623) RELAY2: RPC calls fail on remote site members
by Karim AMMOUS (JIRA)
[ https://issues.jboss.org/browse/JGRP-1623?page=com.atlassian.jira.plugin.... ]
Karim AMMOUS updated JGRP-1623:
-------------------------------
Attachment: Relay2RpcDispatcherTest.java
> RELAY2: RPC calls fail on remote site members
> ---------------------------------------------
>
> Key: JGRP-1623
> URL: https://issues.jboss.org/browse/JGRP-1623
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.8
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Attachments: Relay2RpcDispatcherTest.java
>
>
> Let's
> Site LON : a (site master), b
> Site NYC : x (site master), y
> when b.callRemoteMethods(null, foo method, opts), no method invocation was handled on x and y.
> Message that enclose MethodCall reached the remote site members (x and y), but it was interpreted as notification instead of request. Below stack trace of the exception triggered at NYC receivers.
> Please find enclosed a unitary test.
> {noformat}
> 4034 [ERROR] RELAY2: failed delivering message
> java.lang.RuntimeException: java.lang.ClassCastException: org.jgroups.blocks.MethodCall cannot be cast to java.lang.Integer
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:670) ~[classes/:?]
> at org.jgroups.JChannel.up(JChannel.java:719) ~[classes/:?]
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1008) ~[classes/:?]
> at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:608) [classes/:?]
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452) [classes/:?]
> at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
> at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:419) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:892) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:847) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:668) [classes/:?]
> at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1383) [classes/:?]
> at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1519) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [?:1.6.0_43]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [?:1.6.0_43]
> at java.lang.Thread.run(Thread.java:662) [?:1.6.0_43]
> Caused by: java.lang.ClassCastException: org.jgroups.blocks.MethodCall cannot be cast to java.lang.Integer
> at com.etrali.karim.jgroups.relay.Relay2RpcDispatcherTest$MyReceiver.receive(Relay2RpcDispatcherTest.java:298) ~[bin/:?]
> at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:552) ~[classes/:?]
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667) ~[classes/:?]
> ... 16 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
13 years, 2 months
[JBoss JIRA] (JGRP-1623) RELAY2: RPC calls fail on remote site members
by Karim AMMOUS (JIRA)
Karim AMMOUS created JGRP-1623:
----------------------------------
Summary: RELAY2: RPC calls fail on remote site members
Key: JGRP-1623
URL: https://issues.jboss.org/browse/JGRP-1623
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.8
Reporter: Karim AMMOUS
Assignee: Bela Ban
Let's
Site LON : a (site master), b
Site NYC : x (site master), y
when b.callRemoteMethods(null, foo method, opts), no method invocation was handled on x and y.
Message that enclose MethodCall reached the remote site members (x and y), but it was interpreted as notification instead of request. Below stack trace of the exception triggered at NYC receivers.
Please find enclosed a unitary test.
{noformat}
4034 [ERROR] RELAY2: failed delivering message
java.lang.RuntimeException: java.lang.ClassCastException: org.jgroups.blocks.MethodCall cannot be cast to java.lang.Integer
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:670) ~[classes/:?]
at org.jgroups.JChannel.up(JChannel.java:719) ~[classes/:?]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1008) ~[classes/:?]
at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:608) [classes/:?]
at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:452) [classes/:?]
at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:419) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:892) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:847) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:668) [classes/:?]
at org.jgroups.stack.Protocol.up(Protocol.java:406) [classes/:?]
at org.jgroups.protocols.TP.passBatchUp(TP.java:1383) [classes/:?]
at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1519) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [?:1.6.0_43]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [?:1.6.0_43]
at java.lang.Thread.run(Thread.java:662) [?:1.6.0_43]
Caused by: java.lang.ClassCastException: org.jgroups.blocks.MethodCall cannot be cast to java.lang.Integer
at com.etrali.karim.jgroups.relay.Relay2RpcDispatcherTest$MyReceiver.receive(Relay2RpcDispatcherTest.java:298) ~[bin/:?]
at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:552) ~[classes/:?]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667) ~[classes/:?]
... 16 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
13 years, 2 months
[JBoss JIRA] (AS7-4126) double values cannot be read from dmr response
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4126?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-4126:
---------------------------------------
Unless the original resolution against 7.1.2.Final was incorrect, please file a new issue if this has reappeared.
> double values cannot be read from dmr response
> ----------------------------------------------
>
> Key: AS7-4126
> URL: https://issues.jboss.org/browse/AS7-4126
> Project: Application Server 7
> Issue Type: Bug
> Components: Console
> Affects Versions: 7.1.0.Final
> Reporter: Rob Cernich
> Assignee: Heiko Braun
> Fix For: 7.1.2.Final (EAP)
>
>
> This appears to be a bug in the GWT compiler. The compiler turns the following:
> {code:java|title=DataInput.readDouble()}
> return IEEE754.toDouble(bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++]);
> {code}
> into: (effectively; the GWT compiler is adding a set of parentheses around the parameters passed to the native function)
> {code:java|title=DataInput.readDouble() compiled}
> return IEEE754.toDouble(new byte[] {bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++], bytes[pos++]});
> {code}
> This results in all double values in the model being interpreted as NaN.
> I've patched the code I'm using in SwitchYard as follows:
> {code:java|title=DataInput.java}
> public double readDouble() throws IOException {
> byte doubleBytes[] = new byte[8];
> readFully(doubleBytes);
> return IEEE754.toDouble(doubleBytes);
> }
> {code}
> {code:java|title=IEEE754.java}
> public static native double toDouble(byte[] bytes) /*-{
> var ebits = 11;
> var fbits = 52;
> // Bytes to bits
> var bits = [];
> //snip...
> }
> {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
13 years, 2 months
[JBoss JIRA] (AS7-5359) CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5359?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5359:
----------------------------------
Fix Version/s: 9.0.0.CR1
(was: 8.0.0.Alpha1)
> CLONE - Config XML with <interface ...><any-ipv4-address /></interface> + -Djava.net.preferIPv4Stack=false produces binding to ANY address (error)
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5359
> URL: https://issues.jboss.org/browse/AS7-5359
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Pavel Janousek
> Assignee: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> The same situation is with every shipped and supported configuration/profile. As base for my explanation I'm using standalone.xml. Standalone.xml declares xmlns as:
> {code}
> <server xmlns="urn:jboss:domain:1.3">
> {code}
> The real XSD file which defined elements is jboss-eap-6.0/docs/schema/jboss-as-config_1_3.xsd.
> The very common Linux system has implemented and enabled dualstack in these days. If we instruct AS instance to bind to +any+ IPv4 address via {code}<interface name="public">
> <any-ipv4-address />
> </interface>{code}
> The real result is to bind running AS instance to +any+ IP address, not only in IPv4 address space but in IPv6 too!
> With default setting (= -Djava.net.preferIPv4Stack=true), result is correct - it is bound to ANY IPv4 addresses only.
--
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
13 years, 2 months
[JBoss JIRA] (AS7-6470) Improve reporting during deployment hang
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6470?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6470:
----------------------------------
Assignee: (was: Brian Stansberry)
Fix Version/s: 8.0.0.Beta1
(was: 8.0.0.Alpha1)
> Improve reporting during deployment hang
> ----------------------------------------
>
> Key: AS7-6470
> URL: https://issues.jboss.org/browse/AS7-6470
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Environment: http://java.net/jira/browse/EJB_SPEC-60
> java version "1.7.0_09"
> OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
> Ubuntu 12.10
> Reporter: Carlo de Wolf
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment-hang-20130205.txt, server.log
>
>
> Management Thread waits indefinitely for, what seems to be, a finished operation.
> {noformat}
> "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {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
13 years, 2 months
[JBoss JIRA] (AS7-6964) Recursive expression resolution
by Jess Sightler (JIRA)
[ https://issues.jboss.org/browse/AS7-6964?page=com.atlassian.jira.plugin.s... ]
Jess Sightler commented on AS7-6964:
------------------------------------
I have added an initial pass at an implementation (with the above feature missing) in order to solicit some feedback.
Basically, variable resolution happens in two places:
- The model node itself (System Property and Environment Variable resolution)
- The ExpressionResolver (vault)
I have worked around this by moving the call to node.resolve() into the resolveExpressionsRecursively itself for the moment. I don't really see a way around this with the current design, but it doesn't seem ideal to me.
Suggestions?
> Recursive expression resolution
> -------------------------------
>
> Key: AS7-6964
> URL: https://issues.jboss.org/browse/AS7-6964
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jess Sightler
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.
--
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
13 years, 2 months