[JBoss JIRA] (JBRULES-3515) Getting runtime exception while I remove a validation Rule in version 5.4
by Premasis S (JIRA)
Premasis S created JBRULES-3515:
-----------------------------------
Summary: Getting runtime exception while I remove a validation Rule in version 5.4
Key: JBRULES-3515
URL: https://issues.jboss.org/browse/JBRULES-3515
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.4.0.Final
Reporter: Premasis S
Assignee: Mark Proctor
I am getting the following exception while removing/disabling a Drool Validation Rule, using Drools Version 5.4.FINAL
i.e when I call - knowledgeBase.removeRule("pkg.trade", "2.8.I23");
java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:980)
at java.util.HashMap$EntryIterator.next(HashMap.java:1018)
at java.util.HashMap$EntryIterator.next(HashMap.java:1016)
at org.drools.reteoo.EvalConditionNode.doRemove(EvalConditionNode.java:302)
at org.drools.common.BaseNode.remove(BaseNode.java:109)
at org.drools.reteoo.FromNode.doRemove(FromNode.java:440)
at org.drools.common.BaseNode.remove(BaseNode.java:109)
at org.drools.reteoo.RightInputAdapterNode.doRemove(RightInputAdapterNode.java:285)
at org.drools.common.BaseNode.remove(BaseNode.java:109)
at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:499)
at org.drools.common.BaseNode.remove(BaseNode.java:109)
at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:358)
at org.drools.common.BaseNode.remove(BaseNode.java:109)
at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:261)
at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:460)
at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1107)
at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1085)
at org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:210)
Here is the Rule:
package pkg.trade;
rule "2.8.I23"
when
$trade : Trade()
$trdDeskId : Id() from mediator.getTradingDeskId($trade)
eval(isPositiveId($trdDeskId))
eval($trdDeskId != null && !mediator.isValidTradingDesk($trdDeskId))
then
raiseException(kcontext, $trade, "tradingDeskId", stringValue($trdDeskId));
end
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5564) @EJB doesn't work for JSF 1.2
by Stan Silvert (JIRA)
Stan Silvert created AS7-5564:
---------------------------------
Summary: @EJB doesn't work for JSF 1.2
Key: AS7-5564
URL: https://issues.jboss.org/browse/AS7-5564
Project: Application Server 7
Issue Type: Bug
Components: JSF
Affects Versions: 7.1.2.Final (EAP)
Reporter: Stan Silvert
Assignee: Stan Silvert
Fix For: 7.2.0.Alpha1
If you use the JSF 1.2 implementation that ships with AS, then if you use @EJB with JSF managed beans then the EJB will not be injected. As a workaround you can get a reference via JNDI.
For the fix, we need to break out the injection classes into a separate module. This way, we can make the JSFInjectionProvider link to the interface in the proper JSF impl.
--
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, 9 months
[JBoss JIRA] (AS7-3975) EJB client invocations sometimes hang indefinitely
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3975:
-----------------------------------
Summary: EJB client invocations sometimes hang indefinitely
Key: AS7-3975
URL: https://issues.jboss.org/browse/AS7-3975
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
When running a EJB stress test when the test is over some clients hang indefinitely.
This is a positive test, there are no failures being injected in the test.
{noformat}
"Runner - 16" daemon prio=10 tid=0x00007fb7a0025000 nid=0x4d7a in Object.wait() [0x00007fb78b3f2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:330)
- locked <0x00000006c013ae50> (a java.lang.Object)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
at $Proxy0.getSerialAndIncrement(Unknown Source)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:68)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
I originally filed a feature request to implement a timeout AS7-3811, needless to say this needs to get fixed first.
--
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
13 years, 9 months
[JBoss JIRA] (LOGMGR-51) Allow any filter type to be specified
by James Perkins (JIRA)
James Perkins created LOGMGR-51:
-----------------------------------
Summary: Allow any filter type to be specified
Key: LOGMGR-51
URL: https://issues.jboss.org/browse/LOGMGR-51
Project: JBoss Log Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: James Perkins
Assignee: James Perkins
Currently handlers only allow for expressions of the JBoss Log Manager's filters. This should allow named filters, e.g. filters defined in the configuration, to be specified.
--
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, 9 months
[JBoss JIRA] (AS7-5591) Add color mapping property
by James Perkins (JIRA)
James Perkins created AS7-5591:
----------------------------------
Summary: Add color mapping property
Key: AS7-5591
URL: https://issues.jboss.org/browse/AS7-5591
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
<Nihility> jamezp: hey next time you update the logging management model, could you expose the colormap formatter property?
<Nihility> <pattern-formatter pattern="blah" colormap="error:blue, brightgreen:warn, yellow debug"/>
--
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, 9 months
[JBoss JIRA] (JBBUILD-720) Change modeshape-tools-continuous Jenkins Job Update-Site Output Directory
by Dan Florian (JIRA)
Dan Florian created JBBUILD-720:
-----------------------------------
Summary: Change modeshape-tools-continuous Jenkins Job Update-Site Output Directory
Key: JBBUILD-720
URL: https://issues.jboss.org/browse/JBBUILD-720
Project: JBoss Build System
Issue Type: Task
Components: Maven Builds
Affects Versions: Build Support 2011
Reporter: Dan Florian
Assignee: Nick Boldt
The modeshape-tools-continuous job outputs the ModeShape Tools update-site to here:
/downloads_htdocs/modeshape/builds/staging/modeshape-tools-continuous/all/repo
We would like the path to be (something like) this:
/downloads_htdocs/modeshape/tools/update/{stable|develop}/{helios|indigo|juno|etc}
At a minimum, the path needs to have the "tools" segment as this identifies it from the ModeShape project. What do other projects do as far as stable vs. develop build? Do other project's put the Eclipse release in the path? Please see MODE-1506 for additional questions/discussion.
I was told to get with you on this Nick. Please update this issue's project and component as appropriate as I wasn't sure.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5590) relax the requirement for having EJB bean class no-arg constructor
by Cheng Fang (JIRA)
Cheng Fang created AS7-5590:
-------------------------------
Summary: relax the requirement for having EJB bean class no-arg constructor
Key: AS7-5590
URL: https://issues.jboss.org/browse/AS7-5590
Project: Application Server 7
Issue Type: Feature Request
Components: EE
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: David Lloyd
Currently AS7 requires all EJB bean class to have a public no-arg
constructor, even when cdi is enabled and there is a @Inject constructor.
The deployment of EJB with no default constructor will fail
validation. I understand this is a EJB spec requirement, but I guess it's
more of legacy from pre-CDI days.
I'm wondering if we can relax it, to support EJB bean classes with
only @Inject constructor and no default constructor. This is currently supported in GlassFish/RI.
The stacktrace from validation:
{noformat}
10:13:36,354 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.deployment.unit."test.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "test.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:91)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 5 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor
at org.jboss.as.ejb3.component.EJBValidationConfigurator.configure(EJBValidationConfigurator.java:59)
at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:80)
... 6 more
10:13:36,360 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"test.war\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011030: Could not configure component TestBean
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014227: EJB TestBean of type test.TestBean must have public default constructor"}}
10:13:36,379 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 19ms
{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, 9 months
[JBoss JIRA] (AS7-5588) LdapExtLoginModule fails to load roles when a Custom Principal is specified
by Jess Sightler (JIRA)
Jess Sightler created AS7-5588:
----------------------------------
Summary: LdapExtLoginModule fails to load roles when a Custom Principal is specified
Key: AS7-5588
URL: https://issues.jboss.org/browse/AS7-5588
Project: Application Server 7
Issue Type: Bug
Components: Security
Affects Versions: 7.1.2.Final (EAP)
Reporter: Jess Sightler
Assignee: Anil Saldhana
LdapExtLoginModule.addRole(String) calls:
super.createIdentity(roleName);
This attempts to get the current context classloader for the current thread. Unfortunately, this fails as the context classloader is null.
The callchain is:
createLdapInitContext->rolesSearch->addRole
Lines 432 and 433 of LdapExtLoginModule are:
if (currentTCCL != null)
SecurityActions.setContextClassLoader(null);
This clears the classloader, so the principal class cannot be loaded.
--
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, 9 months
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5497:
----------------------------------
Fix Version/s: (was: 7.1.3.Final (EAP))
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
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, 9 months
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry reopened AS7-5497:
-----------------------------------
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
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, 9 months