September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5563) Upgrade HornetQ to 2.2.21.Final

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5563: ------------------------------------- Summary: Upgrade HornetQ to 2.2.21.Final Key: AS7-5563 URL: https://issues.jboss.org/browse/AS7-5563 Project: Application Server 7 Issue Type: Component Upgrade Components: JMS Reporter: Brian Stansberry Assignee: Andy Taylor Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) -- 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

11 years, 9 months

2
2
0 / 0

[JBoss JIRA] (SECURITY-696) MessageFactory: Fallback to load classes from current class classloader if tccl failed

by Marek Posolda (JIRA)

Marek Posolda created SECURITY-696: -------------------------------------- Summary: MessageFactory: Fallback to load classes from current class classloader if tccl failed Key: SECURITY-696 URL: https://issues.jboss.org/browse/SECURITY-696 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2_2_1 Environment: negotiation 2.2.1.Final, JBoss AS 7.1.2, GateIn portal Reporter: Marek Posolda Assignee: Darran Lofthouse Priority: Minor Currently method MessageFactory.loadClass(String classname) has possibility to load classes only from Thread context classloader (Thread.currentThread().getContextClassLoader()). It could be nice if there is possibility to load classes from different classloader if TCCL failed. The best would be likely classloader of current class MessageFactory (MessageFactory.class.getClassLoader()) because libraries jboss-negotiation-common and jboss-negotiation-spnego are almost always loaded by same classloader (In JBoss AS7, they are part of same module). This enhancement could be helpful for example in GateIn portal integration, as we have custom NegotiationAuthenticator in different module and so we don't need to explicitly mention additional module "org.jboss.security.negotiation" in dependencies of gatein.ear/META-INF/MANIFEST.MF -- 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

11 years, 9 months

1
2
0 / 0

[JBoss JIRA] (AS7-5569) Upgrade to JBoss Negotiation 2.2.2

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-5569: ------------------------------------- Summary: Upgrade to JBoss Negotiation 2.2.2 Key: AS7-5569 URL: https://issues.jboss.org/browse/AS7-5569 Project: Application Server 7 Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3610) Adding an l to make an int a long does not run when doing multiplication.

by John Lundberg (JIRA)

John Lundberg created JBRULES-3610: -------------------------------------- Summary: Adding an l to make an int a long does not run when doing multiplication. Key: JBRULES-3610 URL: https://issues.jboss.org/browse/JBRULES-3610 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.4.0.Final Environment: MacBook Air OSX 10.7.4 in Java 1.6 Reporter: John Lundberg Assignee: Mark Proctor I am trying to do some multiplication in a drool. long grace = 30l/*days*/ * 24 * 60 * 60 * 1000; But, when it runs I get the error: 'Operator ";" expected' I can however do. long grace1 = 30; long grace2 = 24; long grace3 = 60; long grace4 = 1000; long grace = grace1 * grace2 * grace3 * grace3 * grace4; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
5
0 / 0

[JBoss JIRA] (SECURITY-695) Backport SECURITY-631 to negotiation trunk

by Marek Posolda (JIRA)

Marek Posolda created SECURITY-695: -------------------------------------- Summary: Backport SECURITY-631 to negotiation trunk Key: SECURITY-695 URL: https://issues.jboss.org/browse/SECURITY-695 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Negotiation Affects Versions: Negotiation_2_2_1 Environment: Negotiation 2.2.1.Final, JBoss AS 7.1.2, GateIn portal configured for SPNEGO Reporter: Marek Posolda Assignee: Darran Lofthouse Attachments: SECURITY-695.patch The issue SECURITY-631 was fixed in JBoss Negotiation 2.0.4, which was the negotiation version used by EPP. But for some reason, this feature was fixed only in 2.0 branch, but not in negotiation trunk. Currently we need to upgrade GateIn to be used by AS7 and so we use negotiation 2.2.1.Final but feature is not available here. -- 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

11 years, 9 months

2
3
0 / 0

[JBoss JIRA] (JBRULES-3253) A Declared bean's field's initialization expression is ignored if the type is primitive

by Davide Sottara (Created) (JIRA)

A Declared bean's field's initialization expression is ignored if the type is primitive --------------------------------------------------------------------------------------- Key: JBRULES-3253 URL: https://issues.jboss.org/browse/JBRULES-3253 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.3.0.CR1 Reporter: Davide Sottara Assignee: Davide Sottara It should be possible to use valid MVEL expressions to initialize the fields of declared beans (using the default constructor). declare Bean field : int = 3*4 end If the field type is primitive (int, double, ...) or boxed (Integer, Boolean, Float, ...), the expression is ignored -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
9
0 / 0

[JBoss JIRA] (AS7-5354) update HornetQ 2.2.19 connection factory properties

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-5354: -------------------------------- Summary: update HornetQ 2.2.19 connection factory properties Key: AS7-5354 URL: https://issues.jboss.org/browse/AS7-5354 Project: Application Server 7 Issue Type: Enhancement Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 7.2.0.Alpha1 add new properties for connection-factory (and pooled-connection-factory) that are available with HornetQ 2.2.19.Final * compress-large-messages * passwordCodec (to check...) * usedMaskedPassword (not sure about this one...) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3590) ClassCastException in RuleTerminalNode.retractLeftTuple()

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created JBRULES-3590: ------------------------------------------ Summary: ClassCastException in RuleTerminalNode.retractLeftTuple() Key: JBRULES-3590 URL: https://issues.jboss.org/browse/JBRULES-3590 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.4.0.Final Reporter: Toshiya Kobayashi Assignee: Mark Proctor ruleflow-group + lock-on-activate may cause a ClassCastException. {noformat} import org.drools.Person; import org.drools.Cheese; rule R1 ruleflow-group "group1" lock-on-active true when $p : Person() then $p.setName("John"); end rule R2 ruleflow-group "group1" lock-on-active true when $p : Person( name == null ) forall ( Cheese ( type == "cheddar" )) then end {noformat} {noformat} Exception executing consequence for rule "R1" in defaultpkg: java.lang.ClassCastException: java.lang.Boolean cannot be cast to org.drools.spi.Activation at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1212) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1446) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ... Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to org.drools.spi.Activation at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:309) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98) at org.drools.reteoo.NotNode.retractLeftTuple(NotNode.java:216) at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:286) at org.drools.reteoo.AbstractTerminalNode.modifyLeftTuple(AbstractTerminalNode.java:104) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235) at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:432) at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314) at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:470) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:370) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:319) at defaultpkg.Rule_R1_71208af44b274026888141d4be342303.defaultConsequence(Rule_R1_71208af44b274026888141d4be342303.java:8) at defaultpkg.Rule_R1_71208af44b274026888141d4be342303DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) at defaultpkg.Rule_R1_71208af44b274026888141d4be342303DefaultConsequenceInvoker.evaluate(Unknown Source) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1277) ... 35 more {noformat} It's probably due to the change introduced by the commit c6a3beea974234df599c4b3b80749f8ff15d3149 which sets a Boolean to the tuple. {noformat} public boolean createActivation(final LeftTuple tuple, final PropagationContext context, final InternalWorkingMemory workingMemory, final RuleTerminalNode rtn, final boolean reuseActivation ) { ... InternalAgendaGroup agendaGroup = (InternalAgendaGroup) getAgendaGroup( rule.getAgendaGroup() ); if ( rule.getRuleFlowGroup() == null ) { // No RuleFlowNode so add it directly to the Agenda // do not add the activation if the rule is "lock-on-active" and the // AgendaGroup is active if ( rule.isLockOnActive() && agendaGroup.isActive() && agendaGroup.getAutoFocusActivator() != context) { if ( tuple.getObject() == null ) { tuple.setObject( Boolean.TRUE ); // this is so we can do a check with a bit more intent than a null check on modify } return false; } } else { // There is a RuleFlowNode so add it there, instead of the Agenda InternalRuleFlowGroup rfg = (InternalRuleFlowGroup) getRuleFlowGroup( rule.getRuleFlowGroup() ); // do not add the activation if the rule is "lock-on-active" and the // RuleFlowGroup is active if ( rule.isLockOnActive() && rfg.isActive() && agendaGroup.getAutoFocusActivator() != context) { if ( tuple.getObject() == null ) { tuple.setObject( Boolean.TRUE ); // this is so we can do a check with a bit more intent than a null check on modify } return false; } } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
21
0 / 0

[JBoss JIRA] (JBRULES-3604) Updating a fact causes NPE with extends

by Bobby Graham (JIRA)

Bobby Graham created JBRULES-3604: ------------------------------------- Summary: Updating a fact causes NPE with extends Key: JBRULES-3604 URL: https://issues.jboss.org/browse/JBRULES-3604 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.4.0.Final Reporter: Bobby Graham Assignee: Mark Proctor Problem: When there are two rules (A and B) such that B extends A and both A and B reference the same fact in their conditions, calling update on that fact after calling fireAllRules causes a NPE. DRL: {code} package inheritance import org.drools.Address rule "Parent" enabled false when Address(suburb == "xyz") then end rule "Child" extends "Parent" when $addy:Address(street == "123 some street") then System.out.println($addy); end {code} Test: {code} package org.drools.testframework; import org.drools.Address; import org.drools.KnowledgeBase; import org.drools.KnowledgeBaseFactory; import org.drools.builder.KnowledgeBuilder; import org.drools.builder.KnowledgeBuilderFactory; import org.drools.builder.ResourceType; import org.drools.io.Resource; import org.drools.io.ResourceFactory; import org.drools.runtime.StatefulKnowledgeSession; import org.drools.runtime.rule.FactHandle; import org.junit.Test; public class ExternalUpdateInheritanceTest { @Test public void testExternalInheritanceFactUpdates() { KnowledgeBase knowledgeBase = null; KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder(); Resource newClassPathResource = ResourceFactory.newClassPathResource("org/drools/lang/inheritance.drl"); builder.add(newClassPathResource, ResourceType.DRL); if (builder.hasErrors()) { throw new RuntimeException(builder.getErrors().toString()); } knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase(); knowledgeBase.addKnowledgePackages(builder.getKnowledgePackages()); StatefulKnowledgeSession ksession = knowledgeBase.newStatefulKnowledgeSession(); Address address = new Address(); address.setSuburb("xyz"); FactHandle addressHandle = ksession.insert(address); int rulesFired = ksession.fireAllRules(); address.setStreet("123 some street"); ksession.update(addressHandle, address); System.out.println(rulesFired); } } {code} Stack Trace: java.lang.NullPointerException at org.drools.common.DefaultAgenda.createActivation(DefaultAgenda.java:572) at org.drools.reteoo.RuleTerminalNode.modifyLeftTuple(RuleTerminalNode.java:297) at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:297) at org.drools.reteoo.AbstractTerminalNode.modifyLeftTuple(AbstractTerminalNode.java:104) at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205) at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235) at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170) at org.drools.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:68) at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:157) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:421) at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314) at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:474) at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:960) at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:933) at org.drools.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:284) at org.drools.testframework.ExternalUpdateInheritanceTest.testExternalInheritanceFactUpdates(ExternalUpdateInheritanceTest.java:44) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

4
11
0 / 0

[JBoss JIRA] (JBREM-1315) Exception during EJBHome.create()

by Arun Varadharajan (JIRA)

Arun Varadharajan created JBREM-1315: ---------------------------------------- Summary: Exception during EJBHome.create() Key: JBREM-1315 URL: https://issues.jboss.org/browse/JBREM-1315 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Arun Varadharajan -- 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

11 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2012