January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3351) Unable to test http://localhost:8080 after ran domain.cmd

by narayana b (JIRA)

narayana b created AS7-3351: ------------------------------- Summary: Unable to test http://localhost:8080 after ran domain.cmd Key: AS7-3351 URL: https://issues.jboss.org/browse/AS7-3351 Project: Application Server 7 Issue Type: Clarification Components: Server Affects Versions: 7.0.0.Final Environment: windows 7, 32bit os, Reporter: narayana b Assignee: Jason Greene Hi, I have executed jboss_home>domain.cmd and tried to access http://localhost:8080 but unfortunately 404 error forund on my browse. I am not sure why this is displayed on my browser -- 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

14 years

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-3080) Compilation of rules should fail when is not used quotes in a String attribute

by Alessandro Lazarotti (JIRA)

Compilation of rules should fail when is not used quotes in a String attribute ------------------------------------------------------------------------------ Key: JBRULES-3080 URL: https://issues.jboss.org/browse/JBRULES-3080 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.1.FINAL Reporter: Alessandro Lazarotti Assignee: Mark Proctor It is mandatory that Strings are placed between quotes. Guvnor/BRMS or DRL's plain text should fail if you forgot the quotes but currently it just fails the build if you put a value different of numerics: f : Fact( stringAttribute == ab ) It will fail. The same must occur for: f : Fact( stringAttribute == 12 ) ... but it does not happen and the rule is never matched. It is very important keep the same behaviour for both cases. The rule's author needs to know about it before the package is built. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

6
28
0 / 0

[JBoss JIRA] Created: (JBAS-8595) Thread Pooling configuration from jmx-console doesn't update WorkerStack size. Size remains 200 always.

by Nishant Parikh (JIRA)

Thread Pooling configuration from jmx-console doesn't update WorkerStack size. Size remains 200 always. ------------------------------------------------------------------------------------------------------- Key: JBAS-8595 URL: https://jira.jboss.org/browse/JBAS-8595 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX/Web Console Affects Versions: JBossAS-5.0.1.GA Environment: Windows/Linux, JDK1.5, RAM 2GB, Processor 3GHz, Intel Core Due CPU Reporter: Nishant Parikh Assignee: Darran Lofthouse Priority: Critical When we fire concurrent request more than 200, let's say 200+x (With maxThreads specified 1000 from jmx/web console), Everything works fine but after few seconds x NUMBER OF THREADS GETS BUSY and they never get free. On server log we are getting below ArrayIndexOutOfBoundsException. Exception in thread "http-192.168.1.166-8080-4" java.lang.ArrayIndexOutOfBoundsException: 200 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-16" java.lang.ArrayIndexOutOfBoundsException: 201 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-91" java.lang.ArrayIndexOutOfBoundsException: 202 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) Exception in thread "http-192.168.1.166-8080-98" java.lang.ArrayIndexOutOfBoundsException: 203 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.push(JIoEndpoint.java:769) at org.apache.tomcat.util.net.JIoEndpoint.recycleWorkerThread(JIoEndpoint.java:724) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:457) at java.lang.Thread.run(Thread.java:662) 17:08:49,515 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 203 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,530 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 202 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,546 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 201 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) 17:08:49,548 ERROR [JIoEndpoint] Error allocating socket processor java.lang.ArrayIndexOutOfBoundsException: 200 at org.apache.tomcat.util.net.JIoEndpoint$WorkerStack.pop(JIoEndpoint.java:778) at org.apache.tomcat.util.net.JIoEndpoint.createWorkerThread(JIoEndpoint.java:661) at org.apache.tomcat.util.net.JIoEndpoint.getWorkerThread(JIoEndpoint.java:702) at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:737) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:313) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
5
0 / 0

[JBoss JIRA] Created: (AS7-829) make-pristine.sh to reset an AS installation to factory settings

by Bob McWhirter (JIRA)

make-pristine.sh to reset an AS installation to factory settings ---------------------------------------------------------------- Key: AS7-829 URL: https://issues.jboss.org/browse/AS7-829 Project: Application Server 7 Issue Type: Enhancement Reporter: Bob McWhirter Assignee: Jason Greene Not sure how this is better than unzip -q jboss-as-bin.zip, but being able to "reset" the domain and such (and bootstrap logging props) to out-of-the-box settings might be nice. Perhaps a separate script to clean the deployments and content repo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1744) Create an ivy resolver for maven uniquely versioned snapshots

by Carlo de Wolf (JIRA)

Create an ivy resolver for maven uniquely versioned snapshots ------------------------------------------------------------- Key: EJBTHREE-1744 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1744 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
4
0 / 0

[JBoss JIRA] Created: (AS7-1627) Handle NPE for missing destination property on hornetq MDB activation.

by Jeremy Whiting (JIRA)

Handle NPE for missing destination property on hornetq MDB activation. ---------------------------------------------------------------------- Key: AS7-1627 URL: https://issues.jboss.org/browse/AS7-1627 Project: Application Server 7 Issue Type: Enhancement Components: JMS Affects Versions: 7.1.0.Alpha1 Environment: RHEL 5.5 Reporter: Jeremy Whiting Assignee: Clebert Suconic Priority: Minor When a destination property is missing on the hornetq activationConfig the AS7 server throws a NPE. Instead the HornetQActivation object could catch the exception and log a message telling the user to define the missing property. This is the exception stack trace when AS7 starts up. 14:36:55,642 ERROR [org.hornetq.ra.inflow.HornetQActivation] (jca-short-running-threads-threads - 6) Unable to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2f8541f5 destination=null destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): java.lang.NullPointerException at javax.naming.NameImpl.<init>(NameImpl.java:281) [:1.6.0_20] at javax.naming.CompositeName.<init>(CompositeName.java:231) [:1.6.0_20] at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49) at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:393) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) at javax.naming.InitialContext.lookup(InitialContext.java:409) [:1.6.0_20] at org.hornetq.ra.Util.lookup(Util.java:174) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.setupDestination(HornetQActivation.java:436) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.setup(HornetQActivation.java:283) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation.handleFailure(HornetQActivation.java:548) [hornetq-ra-2.2.7.Final.jar:] at org.hornetq.ra.inflow.HornetQActivation$SetupActivation.run(HornetQActivation.java:591) [hornetq-ra-2.2.7.Final.jar:] at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:212) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821) at java.lang.Thread.run(Thread.java:636) [:1.6.0_20] at org.jboss.threads.JBossThread.run(JBossThread.java:122) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2464) Unexpected test failures on IBM JDK 6

by Lukáš Petrovický (JIRA)

Unexpected test failures on IBM JDK 6 ------------------------------------- Key: JBRULES-2464 URL: https://jira.jboss.org/jira/browse/JBRULES-2464 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core, drools-testing Reporter: Lukáš Petrovický Assignee: Mark Proctor See BRMS-287. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
13
0 / 0

[JBoss JIRA] Created: (JBAS-8366) Failure to deploy a war file with JBoss 5.0

by Sasha Matison (JIRA)

Failure to deploy a war file with JBoss 5.0 ------------------------------------------- Key: JBAS-8366 URL: https://jira.jboss.org/browse/JBAS-8366 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.GA Environment: Windows 2003 R2 SP2, JBoss AS 5.0, JDK 1.6_16 Reporter: Sasha Matison Assignee: Scott M Stark Priority: Blocker While deploying our war file with JBoss AS 5.0 we are getting the following error: org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser We are shipping the product with a version of Xerces-j 2.9.1. Removing this version from the product is not an option. Note that the war file used to work with JBoss 4.x. This issue is blocking JBoss 5.0 testing. Please advise on the solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
5
0 / 0

[JBoss JIRA] (JBRULES-3363) Add support to inline constraints on multi-function accumulate

by Edson Tirelli (JIRA)

Edson Tirelli created JBRULES-3363: -------------------------------------- Summary: Add support to inline constraints on multi-function accumulate Key: JBRULES-3363 URL: https://issues.jboss.org/browse/JBRULES-3363 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.4.0.Beta1 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.4.0.Beta2 FROM MARK: =========== Edson, While I don't want to change to acc/for keyword quite yet, until we are sure what drastic changes we want to make to syntax. I think we can evolve accumulate() 1) make the first ", " optionall [,;]. Where the documented new separate is ";" 2) functions are still "," separated 3) allow an optional second ";" after this boolean expression, an eval without the eval wrapper. 3. can be done now with a separate eval(....) after the accumulate. But I think good to encapsulate the intent of the guard within the accumulate itself, it's also another opportunity to remove the "eval" keyword for a common use case. For now we'll just rewrite the accumulate to place an eval() CE after the acc. It's a small win, which I think will make the DRL look nicer, especially for CEP use cases. ============ FROM EDSON: ============ Mark, (1) and (2) are ok. Regarding (3), we can embed the expression in the accumulate node itself. No need for a separate node. And if we use ; as the separator, we don't need the eval() keyword. -- 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

14 years

2
7
0 / 0

[JBoss JIRA] (JBRULES-3320) Stateful memory corruption for repetitive updates on the same facts

by guy ramirez (Created) (JIRA)

Stateful memory corruption for repetitive updates on the same facts ------------------------------------------------------------------- Key: JBRULES-3320 URL: https://issues.jboss.org/browse/JBRULES-3320 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.4.0.Beta1, 5.3.0.Final Environment: Windows 7 64, Java HotSpot(TM) 64-Bit Server 1.6.0_25 Reporter: guy ramirez Assignee: Mark Proctor Multiple updates to the same fact does not yield the expected results (similar to JBRULES-2809 issue) The provided UT (see 'steps to reproduce' section) makes use of 2 fact instances: one IntervalRequirement (never updated) and one ShiftAssignment. The same ShiftAssignment will be updated multiple times to cover one or more IntervalRequirement(s). Here is the output of the test without executing the assertions. For each update I have added comments explaining what the expected results should be: Update #1: ShiftAssignment set from 100 to 101 intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementNotCovered -> IntervalRequirement: interval: 103, staffingRequired: 2 intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 intervalRequirementNotCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 COMMENTS: correct Update #2:ShiftAssignment set from 100 to 103 intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s) COMMENTS: intervalRequirementNotCovered rule should have fired for interval 103 Update #3:ShiftAssignment set from 100 to 102 intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s) COMMENT: intervalRequirementNotCovered rule should have fired for interval 103 Update #4:ShiftAssignment set from 100 to 104 intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 103, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s) intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s) COMMENT: correct Update #5:ShiftAssignment set from 100 to 101 intervalRequirementTotallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 2 ShiftAssignment(s) intervalRequirementNotCovered -> IntervalRequirement: interval: 103, staffingRequired: 2 intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 intervalRequirementNotCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 COMMENT: results should have been identical of that of update #1: intervalRequirementPartiallyCovered should have fired for interval 100, instead intervalRequirementTotallyCovered rule fired. -- 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

14 years

5
10
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2012