[JBoss JIRA] (WFLY-1018) Improve error reporting on misconfigured security-realm
by Aaron Tan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1018?page=com.atlassian.jira.plugin.... ]
Aaron Tan commented on WFLY-1018:
---------------------------------
have you resolved this now,i have meet this error with wildfly.8.1.0 too
> Improve error reporting on misconfigured security-realm
> -------------------------------------------------------
>
> Key: WFLY-1018
> URL: https://issues.jboss.org/browse/WFLY-1018
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Reporter: Alessio Soldano
> Assignee: Tomaz Cerar
> Priority: Minor
>
> I've erroneously configured standalone.xml with an empty (no child) security realm and referenced it in a undertow https listenerer.
> When running a test relying on https, I'm getting the following error only on server side:
> 11:43:44,482 ERROR [org.xnio.listener] (default I/O-3) A channel event listener threw an exception: java.lang.NullPointerException
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:143) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:288) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:285) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-1018) Improve error reporting on misconfigured security-realm
by Aaron Tan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1018?page=com.atlassian.jira.plugin.... ]
Aaron Tan commented on WFLY-1018:
---------------------------------
17:23:14,398 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:145) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> Improve error reporting on misconfigured security-realm
> -------------------------------------------------------
>
> Key: WFLY-1018
> URL: https://issues.jboss.org/browse/WFLY-1018
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Reporter: Alessio Soldano
> Assignee: Tomaz Cerar
> Priority: Minor
>
> I've erroneously configured standalone.xml with an empty (no child) security realm and referenced it in a undertow https listenerer.
> When running a test relying on https, I'm getting the following error only on server side:
> 11:43:44,482 ERROR [org.xnio.listener] (default I/O-3) A channel event listener threw an exception: java.lang.NullPointerException
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:143) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:288) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:285) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) [xnio-nio-3.1.0.CR2.jar:3.1.0.CR2]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (JBAS-9569) NullPointerException at org.jboss.invocation.InvokerInterceptor.invokeInvoker()
by ButchiSubbaiah Nomula (JIRA)
ButchiSubbaiah Nomula created JBAS-9569:
-------------------------------------------
Summary: NullPointerException at org.jboss.invocation.InvokerInterceptor.invokeInvoker()
Key: JBAS-9569
URL: https://issues.jboss.org/browse/JBAS-9569
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Components: EJB
Reporter: ButchiSubbaiah Nomula
Assignee: Carlo de Wolf
I got the below stack trace and could not get what lead to this issue.
INFO | jvm 1 | 2014/11/11 15:05:59 | Caused by: java.lang.NullPointerException
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:63)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.proxy.ejb.SecurityContextInterceptor.invoke(SecurityContextInterceptor.java:64)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
INFO | jvm 1 | 2014/11/11 15:05:59 | at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
INFO | jvm 1 | 2014/11/11 15:05:59 | at com.sun.proxy.$Proxy67.remove(Unknown Source)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-464) ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
by James Livingston (JIRA)
James Livingston created WFCORE-464:
---------------------------------------
Summary: ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
Key: WFCORE-464
URL: https://issues.jboss.org/browse/WFCORE-464
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Alpha14
Reporter: James Livingston
Assignee: Brian Stansberry
org.jboss.as.process.ManagedProcess$ReadTask.run() uses readLine() to read a line of output from the manage process' standard output/error streams, which cause the whole line to be loaded into memory.
Badly written applications may dump excessive amounts of data out in a single line, which would cause the process controller to temporarily use a large amount of memory to process it, potentially leading to an OutOfMemoryError. Practically speaking, with the default -Xmx512m it would require around 128 million characters in a single line to trigger, which is obviously very high.
Were an OOME to occur, it would almost certainly cause the stream to be closed, and "IOException: Broken pipe" exceptions to occur in the child process, which for WildFly would be caught an ignored by JBoss Logging. A hostile managed process exploiting this would be almost impossible.
A reasonable solution would probably be to limit size of the buffer read, causing it to split lines over a certain size (a few megabytes?). That would not likely cause any practical problems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-464) ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-464?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-464:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1114419
> ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-464
> URL: https://issues.jboss.org/browse/WFCORE-464
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha14
> Reporter: James Livingston
> Assignee: Brian Stansberry
>
> org.jboss.as.process.ManagedProcess$ReadTask.run() uses readLine() to read a line of output from the manage process' standard output/error streams, which cause the whole line to be loaded into memory.
> Badly written applications may dump excessive amounts of data out in a single line, which would cause the process controller to temporarily use a large amount of memory to process it, potentially leading to an OutOfMemoryError. Practically speaking, with the default -Xmx512m it would require around 128 million characters in a single line to trigger, which is obviously very high.
> Were an OOME to occur, it would almost certainly cause the stream to be closed, and "IOException: Broken pipe" exceptions to occur in the child process, which for WildFly would be caught an ignored by JBoss Logging. A hostile managed process exploiting this would be almost impossible.
> A reasonable solution would probably be to limit size of the buffer read, causing it to split lines over a certain size (a few megabytes?). That would not likely cause any practical problems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4125:
------------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
> javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
> ---------------------------------------------------------------------------------
>
> Key: WFLY-4125
> URL: https://issues.jboss.org/browse/WFLY-4125
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Sande Gilda
> Assignee: Stuart Douglas
>
> See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293
> The shopping-cart quickstart has a note in the README file that states:
> Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available.
> However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868)
> I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it.
> See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983
> David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3953) @Schedule annotation produces "Cannot invoke timeout method because method null is not a timeout method"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3953?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3953.
----------------------------------
Resolution: Cannot Reproduce Bug
I don't seem to be able to reproduce it. If you still see it with WF9 can you attach a project that replicates the issue?
> @Schedule annotation produces "Cannot invoke timeout method because method null is not a timeout method"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3953
> URL: https://issues.jboss.org/browse/WFLY-3953
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: Andrei Tchijov
> Assignee: Stuart Douglas
>
> Please take a look at this gist : https://gist.github.com/leapingbytes/01838d9534638cb04200
> In case of @Schedule second and all consecutive invocations produce this
> {code}
> 13:19:30,635 ERROR U( ) [org.jboss.as.ejb3] (EJB default - 8) JBAS014120: Error invoking timeout for timer: [id=ba9f1c67-5a91-42ff-8276-f715efaa3723 timedObjectId=ChumbaServer-2.0-SNAPSHOT.ChumbaServer-2.0-SNAPSHOT.SettingsManagerImpl auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5a898863 initialExpiration=Wed Oct 08 13:17:30 EEST 2014 intervalDuration(in milli sec)=60000 nextExpiration=Wed Oct 08 13:20:30 EEST 2014 timerState=IN_TIMEOUT info=null: java.lang.RuntimeException: JBAS014481: Cannot invoke timeout method because method null is not a timeout method
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:84) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:114) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.callTimeout(TimerTask.java:196) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:168) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-670) Generalize inline casts to work with traits
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-670:
-------------------------------------
Summary: Generalize inline casts to work with traits
Key: DROOLS-670
URL: https://issues.jboss.org/browse/DROOLS-670
Project: Drools
Issue Type: Enhancement
Affects Versions: 6.2.0.CR3
Reporter: Davide Sottara
Assignee: Davide Sottara
Fix For: 6.2.0.Final
The following constraint
{code}
Person( this#Worker( wage > 1000 ) )
{code}
is admissible when Worker is a subtype of Person.
It should also be possible to use "#" when Worker is a donned trait.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-669:
-------------------------------------
Summary: Create "behavesAs" operator to support traiting
Key: DROOLS-669
URL: https://issues.jboss.org/browse/DROOLS-669
Project: Drools
Issue Type: Feature Request
Affects Versions: 6.2.0.CR3
Reporter: Davide Sottara
Assignee: Davide Sottara
Fix For: 6.2.0.Final
Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4179) Three web integration test failures with security manager enabled
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4179?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4179:
------------------------------------
Assignee: Stuart Douglas (was: Stefan Guilhen)
> Three web integration test failures with security manager enabled
> -----------------------------------------------------------------
>
> Key: WFLY-4179
> URL: https://issues.jboss.org/browse/WFLY-4179
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Reporter: James Perkins
> Assignee: Stuart Douglas
> Attachments: org.jboss.as.test.integration.jsp.JspTagTestCase-output.txt, org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase-output.txt, org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase.txt
>
>
> The following 3 tests fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
> * org.jboss.as.test.integration.jsp.JspTagTestCase
> * org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase
> * org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
> The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years