[JBoss JIRA] (DROOLS-78) NullPointerException in Length Window
by Radai Rosenblatt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-78?page=com.atlassian.jira.plugin.... ]
Radai Rosenblatt updated DROOLS-78:
-----------------------------------
Attachment: droolsIssue.zip
maven porject recreating DROOLS-78
> NullPointerException in Length Window
> -------------------------------------
>
> Key: DROOLS-78
> URL: https://issues.jboss.org/browse/DROOLS-78
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Reporter: Radai Rosenblatt
> Assignee: Mark Proctor
> Attachments: droolsIssue.zip
>
>
> when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
> the exception produced is:
> java.lang.NullPointerException
> at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
> at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
> at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
> at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
--
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, 4 months
[JBoss JIRA] (DROOLS-78) NullPointerException in Length Window
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created DROOLS-78:
--------------------------------------
Summary: NullPointerException in Length Window
Key: DROOLS-78
URL: https://issues.jboss.org/browse/DROOLS-78
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
the exception produced is:
java.lang.NullPointerException
at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
--
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, 4 months
[JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Alexey Tomin (JIRA)
[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ]
Alexey Tomin commented on AS7-6367:
-----------------------------------
Also error use remote ejb (with custom roles module) and remote jms...
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6367
> URL: https://issues.jboss.org/browse/AS7-6367
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Derek Horton
> Assignee: jaikiran pai
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
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, 4 months
[JBoss JIRA] (AS7-6426) Jboss-cli crashes on Windows on backslash in history
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6426?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6426:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 920344|https://bugzilla.redhat.com/show_bug.cgi?id=920344] from NEW to MODIFIED
> Jboss-cli crashes on Windows on backslash in history
> ----------------------------------------------------
>
> Key: AS7-6426
> URL: https://issues.jboss.org/browse/AS7-6426
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows 7, 64-bit
> Reporter: Jarkko Rantavuori
> Assignee: Ståle Pedersen
> Fix For: 8.0.0.Alpha1
>
>
> Note: seems to apply to latest snapshot only, not to 7.1.1.
> If you use a backslash in commands (like you need to use on absolute path deployments on windows) and then press up button to go back to that command, jboss-cli crashes with
> java.lang.NumberFormatException: For input string: "1B"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:492)
> at java.lang.Integer.<init>(Integer.java:677)
> at org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:120)
> at java.io.FilterOutputStream.write(FilterOutputStream.java:125)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.PrintWriter.flush(PrintWriter.java:320)
> at org.jboss.aesh.terminal.WindowsTerminal.writeToStdOut(WindowsTerminal.java:89)
> at org.jboss.aesh.console.Console.drawLine(Console.java:923)
> at org.jboss.aesh.console.Console.redrawLine(Console.java:902)
> at org.jboss.aesh.console.Console.getHistoryElement(Console.java:673)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:476)
> at org.jboss.aesh.console.Console.read(Console.java:377)
> at org.jboss.aesh.console.Console.read(Console.java:331)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:171)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1181)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> Press any key to continue . . .
--
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, 4 months
[JBoss JIRA] (JBVFS-187) AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
by Chris Sams (JIRA)
[ https://issues.jboss.org/browse/JBVFS-187?page=com.atlassian.jira.plugin.... ]
Chris Sams updated JBVFS-187:
-----------------------------
Fix Version/s: (was: 2.2.1.GA)
> AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBVFS-187
> URL: https://issues.jboss.org/browse/JBVFS-187
> Project: JBoss VFS
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Release
> Affects Versions: 2.2.0.GA, 2.2.0.SP1
> Reporter: Chris Sams
> Assignee: Chris Sams
> Priority: Minor
>
> This is to strict, it should be INFO or even less.
> What we're trying to do here is get a real (non-temp) URL, for that we use original handler.
> And then try to get a child off this old handler, where since removed, is null.
> So we try our best to re-ceate the original url - hence warning.
> This can occur in normal operations such as when using a jboss-structure.xml:
> <structure>
> <context modification="temp">
> <path name=""/>
> <metaDataPath>
> <path name="WEB-INF"/>
> </metaDataPath>
> <classpath>
> <path name="WEB-INF/classes"/>
> <path name="WEB-INF/lib" suffixes=".jar"/>
> </classpath>
> </context>
> </structure>
> And if you deploy an exploded deployment and then remove it from the deploy directory triggering a undeploy will cause the warning.
> 22:20:08,625 WARN [AbstractVirtualFileHandler] No such existing handler, falling back to old root + path: vfszip:/home/applications/servers/eap/jboss-eap-5.1.2/jboss-as/server/default/deploy/springtest3.2.war/WEB-INF/lib/spring-web-3.2.0.M2.jar/org/springframework/web/context/ContextCleanupListener.class
--
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, 4 months
[JBoss JIRA] (JBVFS-187) AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
by Chris Sams (JIRA)
[ https://issues.jboss.org/browse/JBVFS-187?page=com.atlassian.jira.plugin.... ]
Chris Sams updated JBVFS-187:
-----------------------------
Affects Version/s: 2.2.1.GA
> AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBVFS-187
> URL: https://issues.jboss.org/browse/JBVFS-187
> Project: JBoss VFS
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Release
> Affects Versions: 2.2.0.GA, 2.2.0.SP1, 2.2.1.GA
> Reporter: Chris Sams
> Assignee: Chris Sams
> Priority: Minor
>
> This is to strict, it should be INFO or even less.
> What we're trying to do here is get a real (non-temp) URL, for that we use original handler.
> And then try to get a child off this old handler, where since removed, is null.
> So we try our best to re-ceate the original url - hence warning.
> This can occur in normal operations such as when using a jboss-structure.xml:
> <structure>
> <context modification="temp">
> <path name=""/>
> <metaDataPath>
> <path name="WEB-INF"/>
> </metaDataPath>
> <classpath>
> <path name="WEB-INF/classes"/>
> <path name="WEB-INF/lib" suffixes=".jar"/>
> </classpath>
> </context>
> </structure>
> And if you deploy an exploded deployment and then remove it from the deploy directory triggering a undeploy will cause the warning.
> 22:20:08,625 WARN [AbstractVirtualFileHandler] No such existing handler, falling back to old root + path: vfszip:/home/applications/servers/eap/jboss-eap-5.1.2/jboss-as/server/default/deploy/springtest3.2.war/WEB-INF/lib/spring-web-3.2.0.M2.jar/org/springframework/web/context/ContextCleanupListener.class
--
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, 4 months
[JBoss JIRA] (AS7-6426) Jboss-cli crashes on Windows on backslash in history
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6426?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved AS7-6426.
-----------------------------------
Assignee: Ståle Pedersen (was: Alexey Loubyansky)
Fix Version/s: 8.0.0.Alpha1
Resolution: Done
> Jboss-cli crashes on Windows on backslash in history
> ----------------------------------------------------
>
> Key: AS7-6426
> URL: https://issues.jboss.org/browse/AS7-6426
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Windows 7, 64-bit
> Reporter: Jarkko Rantavuori
> Assignee: Ståle Pedersen
> Fix For: 8.0.0.Alpha1
>
>
> Note: seems to apply to latest snapshot only, not to 7.1.1.
> If you use a backslash in commands (like you need to use on absolute path deployments on windows) and then press up button to go back to that command, jboss-cli crashes with
> java.lang.NumberFormatException: For input string: "1B"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:492)
> at java.lang.Integer.<init>(Integer.java:677)
> at org.fusesource.jansi.AnsiOutputStream.write(AnsiOutputStream.java:120)
> at java.io.FilterOutputStream.write(FilterOutputStream.java:125)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.PrintWriter.flush(PrintWriter.java:320)
> at org.jboss.aesh.terminal.WindowsTerminal.writeToStdOut(WindowsTerminal.java:89)
> at org.jboss.aesh.console.Console.drawLine(Console.java:923)
> at org.jboss.aesh.console.Console.redrawLine(Console.java:902)
> at org.jboss.aesh.console.Console.getHistoryElement(Console.java:673)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:476)
> at org.jboss.aesh.console.Console.read(Console.java:377)
> at org.jboss.aesh.console.Console.read(Console.java:331)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:171)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1181)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.modules.Module.run(Module.java:270)
> at org.jboss.modules.Main.main(Main.java:294)
> Press any key to continue . . .
--
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, 4 months
[JBoss JIRA] (AS7-6694) Add attributes to "RemoteConnectionFactory" to make it ready for failover in HA profiles
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6694?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6694:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 919016|https://bugzilla.redhat.com/show_bug.cgi?id=919016] from POST to MODIFIED
> Add attributes to "RemoteConnectionFactory" to make it ready for failover in HA profiles
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6694
> URL: https://issues.jboss.org/browse/AS7-6694
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Alpha1
>
>
> At this moment "RemoteConnectionFactory" configured in messaging subsystem in standalone-full-ha.xml or domain.xml in "full-ha" profile is not ready to failover by default. Please change:
> <connection-factory name="RemoteConnectionFactory">
> <connectors>
> <connector-ref connector-name="netty"/>
> </connectors>
> <entries>
> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
> </entries>
> </connection-factory>
> to:
> <connection-factory name="RemoteConnectionFactory">
> <connectors>
> <connector-ref connector-name="netty"/>
> </connectors>
> <entries>
> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
> </entries>
> <ha>true</ha>
> <block-on-acknowledge>true</block-on-acknowledge>
> <retry-interval>1000</retry-interval>
> <retry-interval-multiplier>1.0</retry-interval-multiplier>
> <reconnect-attempts>-1</reconnect-attempts>
> </connection-factory>
> This will guarantee that clients using this connection factory will failover to backup.
--
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, 4 months