September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1900) Inconsistent class space with package from javaee.api

by Thomas Diesler (JIRA)

Inconsistent class space with package from javaee.api ------------------------------------------------------ Key: AS7-1900 URL: https://issues.jboss.org/browse/AS7-1900 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3210) NPE in Fusion's BrokerExample since 5.3

by Geoffrey De Smet (JIRA)

NPE in Fusion's BrokerExample since 5.3 --------------------------------------- Key: JBRULES-3210 URL: https://issues.jboss.org/browse/JBRULES-3210 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.3.0.Beta1 Reporter: Geoffrey De Smet Assignee: Edson Tirelli Priority: Critical Fix For: 5.3.0.CR1 {code} org.drools.runtime.rule.ConsequenceException: rule: Update stock price at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1100) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1029) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1250) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:733) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:699) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218) at org.drools.examples.broker.Broker.receive(Broker.java:71) at org.drools.examples.broker.events.EventFeeder$FeedJob.execute(EventFeeder.java:85) at org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:151) at org.drools.time.impl.JDKTimerService$JDKCallableJob.call(JDKTimerService.java:126) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.PropagationQueuingNode$PropagateAction@1ba4159 at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:996) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:473) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:365) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:298) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:306) at org.drools.base.ModifyInterceptor.doAfter(ModifyInterceptor.java:59) at org.mvel2.ast.InterceptorWrapper.getReducedValueAccelerated(InterceptorWrapper.java:38) at org.mvel2.MVELRuntime.execute(MVELRuntime.java:89) at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:125) at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:118) at org.mvel2.MVEL.executeExpression(MVEL.java:928) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:105) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1090) ... 16 more Caused by: java.lang.NullPointerException at org.drools.core.util.RightTupleIndexHashTable.removeAdd(RightTupleIndexHashTable.java:321) at org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:229) at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:431) at org.drools.reteoo.JoinNode.modifyObject(JoinNode.java:463) at org.drools.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:68) at org.drools.reteoo.PropagationQueuingNode$ModifyAction.execute(PropagationQueuingNode.java:391) at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:225) at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:438) at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:994) ... 28 more {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Updated: (AS7-1816) DC down, domain.sh with --cached-dc option doesn't start on slave node

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/AS7-1816?page=com.atlassian.jira.plugin.s... ] Rostislav Svoboda updated AS7-1816: ----------------------------------- Issue Type: Bug (was: Feature Request) Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > DC down, domain.sh with --cached-dc option doesn't start on slave node > ---------------------------------------------------------------------- > > Key: AS7-1816 > URL: https://issues.jboss.org/browse/AS7-1816 > Project: Application Server 7 > Issue Type: Bug > Components: Scripts > Affects Versions: 7.0.1.Final > Reporter: Rostislav Svoboda > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.1.0.Beta1 > > > I have local copy of the domain configuration (using -backup), file domain.cached-remote.xml exists. > Can't start domain.sh (with --cached-dc) when DC is down, script ends with could not connect to remote server error. > *Details:* > (Master instance = MI, slave instance = SI, both on the same machine, EAP6 instances copied into different directories) > MI> just start bin/domain.sh > SI: remove all domain/configuration/domain* (optional) > SI: change name attribute of host element in domain/configuration/host.xml > SI: change interfaces definition to public IP address in domain/configuration/host.xml > SI: change domain-controller definition to use remote domain controller (127.0.0.1 in my case) in domain/configuration/host.xml > SI: run bin/domain.sh --backup > MI> shutdown EAP6 instance > SI: shutdown EAP6 instance > SI: make sure file domain/configuration/domain.cached-remote.xml > SI: run bin/domain.sh --cached-dc > SI: there is error, DC couldn't be contacted > log: > {code} > [Host Controller] 09:01:06,861 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3 > [Host Controller] 09:01:11,980 WARN [org.jboss.as.domain.controller] (Controller Boot Thread) Could not connect to remote domain controller 127.0.0.1:9999 > [Host Controller] 09:01:12,083 ERROR [stderr] (Controller Boot Thread) Exception in thread "Controller Boot Thread" java.lang.IllegalStateException: java.net.ConnectException: Could not connect to remote server at 5000 within 5000ms > [Host Controller] 09:01:12,083 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.connect(RemoteDomainConnectionService.java:238) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.register(RemoteDomainConnectionService.java:159) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:291) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:662) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) Caused by: java.net.ConnectException: Could not connect to remote server at 5000 within 5000ms > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.protocol.ProtocolChannelClient.connect(ProtocolChannelClient.java:144) > [Host Controller] 09:01:12,085 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.connect(RemoteDomainConnectionService.java:221) > [Host Controller] 09:01:12,085 ERROR [stderr] (Controller Boot Thread) ... 4 more > {code} > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (AS7-1816) DC down, domain.sh with --cached-dc option doesn't start on slave node

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/AS7-1816?page=com.atlassian.jira.plugin.s... ] Rostislav Svoboda updated AS7-1816: ----------------------------------- Summary: DC down, domain.sh with --cached-dc option doesn't start on slave node (was: CLONE - DC down, domain.sh with --cached-dc option doesn't start on slave node) > DC down, domain.sh with --cached-dc option doesn't start on slave node > ---------------------------------------------------------------------- > > Key: AS7-1816 > URL: https://issues.jboss.org/browse/AS7-1816 > Project: Application Server 7 > Issue Type: Feature Request > Components: Scripts > Affects Versions: 7.0.1.Final > Reporter: Rostislav Svoboda > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > I have local copy of the domain configuration (using -backup), file domain.cached-remote.xml exists. > Can't start domain.sh (with --cached-dc) when DC is down, script ends with could not connect to remote server error. > *Details:* > (Master instance = MI, slave instance = SI, both on the same machine, EAP6 instances copied into different directories) > MI> just start bin/domain.sh > SI: remove all domain/configuration/domain* (optional) > SI: change name attribute of host element in domain/configuration/host.xml > SI: change interfaces definition to public IP address in domain/configuration/host.xml > SI: change domain-controller definition to use remote domain controller (127.0.0.1 in my case) in domain/configuration/host.xml > SI: run bin/domain.sh --backup > MI> shutdown EAP6 instance > SI: shutdown EAP6 instance > SI: make sure file domain/configuration/domain.cached-remote.xml > SI: run bin/domain.sh --cached-dc > SI: there is error, DC couldn't be contacted > log: > {code} > [Host Controller] 09:01:06,861 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3 > [Host Controller] 09:01:11,980 WARN [org.jboss.as.domain.controller] (Controller Boot Thread) Could not connect to remote domain controller 127.0.0.1:9999 > [Host Controller] 09:01:12,083 ERROR [stderr] (Controller Boot Thread) Exception in thread "Controller Boot Thread" java.lang.IllegalStateException: java.net.ConnectException: Could not connect to remote server at 5000 within 5000ms > [Host Controller] 09:01:12,083 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.connect(RemoteDomainConnectionService.java:238) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.register(RemoteDomainConnectionService.java:159) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:291) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:662) > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) Caused by: java.net.ConnectException: Could not connect to remote server at 5000 within 5000ms > [Host Controller] 09:01:12,084 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.protocol.ProtocolChannelClient.connect(ProtocolChannelClient.java:144) > [Host Controller] 09:01:12,085 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.host.controller.RemoteDomainConnectionService.connect(RemoteDomainConnectionService.java:221) > [Host Controller] 09:01:12,085 ERROR [stderr] (Controller Boot Thread) ... 4 more > {code} > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-621) Update JASPI dependency to org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.0_spec

by Stefan Guilhen (JIRA)

Update JASPI dependency to org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.0_spec ---------------------------------------------------------------------------------------------- Key: SECURITY-621 URL: https://issues.jboss.org/browse/SECURITY-621 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: PicketBox_v4_0_2 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: PicketBox_v4_0_3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-619) Support for Subject.doAsPrivileged and Subject.getSubject usage

by Anil Saldhana (JIRA)

Support for Subject.doAsPrivileged and Subject.getSubject usage --------------------------------------------------------------- Key: SECURITY-619 URL: https://issues.jboss.org/browse/SECURITY-619 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v4_0_3 Before the JAAS login is invoked, there is a need to perform Subject.doAs and test out that Subject.getSubject returns the subject. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-620) Vault should have an exists method

by Anil Saldhana (JIRA)

Vault should have an exists method ---------------------------------- Key: SECURITY-620 URL: https://issues.jboss.org/browse/SECURITY-620 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PicketBox Affects Versions: PicketBox_v4_0_2 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v4_0_3 This method can check whether an attribute value for a vault_block/attribute_name combo exists in the vault. This is an api change. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (AS7-1863) Command line switch interprocess-hc-port doesn't take effect

by Brian Stansberry (JIRA)

Command line switch interprocess-hc-port doesn't take effect ------------------------------------------------------------ Key: AS7-1863 URL: https://issues.jboss.org/browse/AS7-1863 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.1.0.Beta1 Rostislav Svoboda reports: I tried --pc-port and --interprocess-hc-port args on build from today's sources. Argument --pc-port is working as expected, but parameter from --interprocess-hc-port argument isn't reflected. Help says it's port on which the host controller should listen for communication from the process controller. Shouldn't be there connection 127.0.0.1:11111 <--> 127.0.0.1:22222 in my example below ? $ ./bin/domain.sh --pc-port=11111 --interprocess-hc-port=22222 $ netstat -natup | grep java tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 31299/java tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 31329/java tcp 0 0 127.0.0.1:1240 0.0.0.0:* LISTEN 31335/java tcp 0 0 127.0.0.1:1241 0.0.0.0:* LISTEN 31335/java tcp 0 0 127.0.0.1:1090 0.0.0.0:* LISTEN 31329/java tcp 0 0 127.0.0.1:1091 0.0.0.0:* LISTEN 31329/java tcp 0 0 127.0.0.1:8230 0.0.0.0:* LISTEN 31335/java tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 31299/java tcp 0 0 127.0.0.1:11111 0.0.0.0:* LISTEN 31284/java tcp 0 0 127.0.0.1:11111 127.0.0.1:49368 SPOJENO 31284/java tcp 0 0 127.0.0.1:9999 127.0.0.1:45597 SPOJENO 31299/java tcp 0 0 127.0.0.1:45597 127.0.0.1:9999 SPOJENO 31329/java tcp 0 0 127.0.0.1:48827 127.0.0.1:9999 SPOJENO 31335/java tcp 0 0 127.0.0.1:49368 127.0.0.1:11111 SPOJENO 31299/java tcp 0 0 127.0.0.1:9999 127.0.0.1:48827 SPOJENO 31299/java NOTE: SPOJENO == ESTABLISHED, PID 31284 is process-controller, PID 31299 is host-controller -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-8938) Separate $JAVA_OPTS for ProcessController and HostController

by Brian Stansberry (JIRA)

Separate $JAVA_OPTS for ProcessController and HostController ------------------------------------------------------------ Key: JBAS-8938 URL: https://issues.jboss.org/browse/JBAS-8938 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry The way domain.sh and domain.conf work now, whatever value gets assigned to $JAVA_OPTS gets passed to java, so affects the vm used for the ProcessController, and then gets passed through as a param to the PC which uses it for creating the HostController process. We should have a separate variable for the PC, or perhaps use $JAVA_OPTS for neither and have 2 new variables. Settings for the PC are unlikely to be optimum for the HC, and using the same var makes it harder to set of debugging (e.g. both the PC and HC process will try and use the same port for remote socket debugging.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1890) Removing <long.running-threads> doesn't work

by Jesper Pedersen (JIRA)

Removing <long.running-threads> doesn't work -------------------------------------------- Key: AS7-1890 URL: https://issues.jboss.org/browse/AS7-1890 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.1.0.Alpha1 Reporter: Jesper Pedersen Assignee: Stefano Maestri Priority: Critical Fix For: 7.1.0.Beta1 Removing <long-running-threads> from the JCA results in a missing service dependency. If the <long-running-threads> isn't defined it should use the <short-running-threads> one instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2011