April 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3437) SAXParseException configuring event listeners in spring

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3437: ------------------------------------ Summary: SAXParseException configuring event listeners in spring Key: JBRULES-3437 URL: https://issues.jboss.org/browse/JBRULES-3437 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco Part of my spring configuration: <drools:ksession id="statefulSession" type="stateful" kbase="kbase1"> <drools:workingMemoryEventListener> <bean class="org.drools.event.DebugWorkingMemoryEventListener"/> </drools:workingMemoryEventListener> <drools:processEventListener> <bean class="org.drools.event.DebugProcessEventListener"/> </drools:processEventListener> </drools:ksession> throws : Caused by: org.xml.sax.SAXParseException; lineNumber: 15; columnNumber: 41; cvc-complex-type.2.4.a: Invalid content was found starting with element 'drools:processEventListener'. One of '{"http://drools.org/schema/drools-spring":workingMemoryEventListener, "http://drools.org/schema/drools-spring":batch, "http://drools.org/schema/drools-spring":script, "http://drools.org/schema/drools-spring":configuration}' is expected. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:387) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:321) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:421) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3186) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1810) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:709) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:376) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:239) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:288) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388) But following configuration is OK: <drools:ksession id="statefulSession" type="stateful" kbase="kbase1"> <drools:processEventListener> <bean class="org.drools.event.DebugProcessEventListener"/> </drools:processEventListener> </drools:ksession> Also this configuration is OK: <drools:ksession id="statefulSession" type="stateful" kbase="kbase1"> <drools:workingMemoryEventListener> <bean class="org.drools.event.DebugWorkingMemoryEventListener"/> </drools:workingMemoryEventListener> </drools:ksession> Exception occurs only when both listeners are configured. probably because of bad position of elements; when listeners configured inside <drools:ksession> as shown above, current order required: agendaEventListener processEventListener workingMemoryEventListener but when configured through <drools:eventListeners> element and listeners attribute in <drools:ksession> element, order of event listeners does not matter. I think this is because of <xsd:all> resp. <xsd:sequence> inside drools-spring.xsd. It would by nice to unite both styles of configuration. -- 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 months

2
11
0 / 0

[JBoss JIRA] (JBRULES-3375) Adding ProcessEventListener throws NPE

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3375: ------------------------------------ Summary: Adding ProcessEventListener throws NPE Key: JBRULES-3375 URL: https://issues.jboss.org/browse/JBRULES-3375 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco Description of problem: When you try to add a ProcessEventListener to StatefulKnowledgeSession and you are missing jBPM libraries on classpath, you get a NullPointerException. Version-Release number of selected component (if applicable): BRMS-5.3.0.dev5 Drools-5.3.0.Final How reproducible: Using attached reproducer. Steps to Reproduce: 1. Make sure you don't have any jBPM libs on classpath 2. Create stateful session 3. Add ProcesEventListener (e.g. DebugProcessEventListener) Actual results: java.lang.NullPointerException at org.drools.impl.StatefulKnowledgeSessionImpl.addEventListener(StatefulKnowledgeSessionImpl.java:199) at org.sample.TryProcessListener.main(TryProcessListener.java:20) Expected results: Either meaningful exception (like NojBPMException) or correct addition of listener Additional info: It only affects StatefulKnowledgeSession, the StatefulKnowledgeSession runs just fine. -- 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 months

2
12
0 / 0

[JBoss JIRA] (AS7-4085) Improve testing of Infinispoan subsystem management features

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-4085: ---------------------------------------- Summary: Improve testing of Infinispoan subsystem management features Key: AS7-4085 URL: https://issues.jboss.org/browse/AS7-4085 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.0.Final Reporter: Richard Achmatowicz Assignee: Paul Ferraro Fix For: 7.1.2.Final We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation. >From the documentation: {noformat} Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model into a new model that matches the first one, execute a "describe" operation for the model, create yet another model from executing the results of that describe operation, and compare that model to first model. {noformat} Over and above these tests, we need more specific tests which cover use cases such as: - every attribute can be read/written as required and that the subsequent reload-required state is as expected - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem - validating that the XML configuration specified gets translated into the desired Infinispan configuration - and many others -- 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 months

2
3
0 / 0

[JBoss JIRA] Created: (AS7-1815) Provide management use cases and operations for the remoting subsystem

by Heiko Braun (JIRA)

Provide management use cases and operations for the remoting subsystem ---------------------------------------------------------------------- Key: AS7-1815 URL: https://issues.jboss.org/browse/AS7-1815 Project: Application Server 7 Issue Type: Feature Request Components: Remoting Reporter: Heiko Braun Assignee: David Lloyd Fix For: 7.1.0.Alpha1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

7
9
0 / 0

[JBoss JIRA] (AS7-4083) Implement JMX-style management access to JGroups components

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-4083: ---------------------------------------- Summary: Implement JMX-style management access to JGroups components Key: AS7-4083 URL: https://issues.jboss.org/browse/AS7-4083 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Affects Versions: 7.1.0.Final Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Fix For: 7.1.2.Final Provide MBean style access to the underlying components of JGroups. We should provide at least the access which was formerly provided by JMX. -- 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 months

2
1
0 / 0

[JBoss JIRA] (AS7-3488) Make default-cache attribute of cache-container "eventually required" rather than required.

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created AS7-3488: ---------------------------------------- Summary: Make default-cache attribute of cache-container "eventually required" rather than required. Key: AS7-3488 URL: https://issues.jboss.org/browse/AS7-3488 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Affects Versions: 7.1.0.CR1b Reporter: Richard Achmatowicz Assignee: Richard Achmatowicz Fix For: 7.1.0.Final Can we remove the restriction that default-cache must be set when you create the cache-container? That way, I can just make it so the UI forces them to set that value before calling the start operation. So under that covers, the console does this: {noformat}  /subsystem=infinispan/cache-container=X:add  /subsystem=infinispan/cache-container=X:write-attribute(name=jndi-name,value=W)  /subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=stack, value=udp) /subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=lock-timeout, value=100)   /subsystem=infinispan/cache-container=X:write-attribute(name=default-cache, value=Y) /subsystem=infinispan/cache-container=X:start(mode=on-demand) {noformat} Any thoughts on this? The answer has great implications on the UI design. -- 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 months

4
27
0 / 0

[JBoss JIRA] (AS7-4015) init.d script, jboss-as/bin/init.d/jboss-as-standalone.sh tests for *executable* /etc/rc.d/init.d/functions

by Leo Breuss (JIRA)

Leo Breuss created AS7-4015: ------------------------------- Summary: init.d script, jboss-as/bin/init.d/jboss-as-standalone.sh tests for *executable* /etc/rc.d/init.d/functions Key: AS7-4015 URL: https://issues.jboss.org/browse/AS7-4015 Project: Application Server 7 Issue Type: Bug Components: Documentation, Scripts Affects Versions: 7.1.0.Final Environment: CentOS 6.2 (netinstall, all default) Reporter: Leo Breuss Assignee: Brian Stansberry Fix For: 7.1.1.Final On CentOS 6 (and maybe other Distros too), the /etc/rc.d/init.d/functions has no executable flag set. The jboss init.d script itself sources it with ". /etc/rc.d/init.d/functions" ll /etc/rc.d/init.d/functions -rw-r--r--. 1 root root 18171 Oct 7 16:01 /etc/rc.d/init.d/functions On line 89, the supplied init script jboss-as-standalone.sh does a check if /etc/rc.d/init.d/functions is executable. So you might want to fix the jboss init.d script the following way: # diff /opt/jboss-as/bin/init.d/jboss-as-standalone.sh /etc/init.d/jboss 89c89 < if [ -x /etc/rc.d/init.d/functions ]; then --- > if [ -r /etc/rc.d/init.d/functions ]; then -- 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 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-9026) Create JBoss AS Javadoc aggregate project

by David Lloyd (JIRA)

Create JBoss AS Javadoc aggregate project ----------------------------------------- Key: JBAS-9026 URL: https://issues.jboss.org/browse/JBAS-9026 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: David Lloyd Assignee: John Casey Fix For: 7.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

12
84
0 / 0

[JBoss JIRA] (AS7-2897) Intermittent failures in IIOP tests

by Brian Stansberry (Created) (JIRA)

Intermittent failures in IIOP tests ----------------------------------- Key: AS7-2897 URL: https://issues.jboss.org/browse/AS7-2897 Project: Application Server 7 Issue Type: Bug Components: IIOP Reporter: Brian Stansberry Assignee: Stefan Guilhen Fix For: 7.1.0.CR1 See, for example, 8 of the 10 failures in https://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-git... The same 8 failures occasionally pop up on my local test runs. -- 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 months

5
5
0 / 0

[JBoss JIRA] (AS7-4647) JSF Version retrieved from deployment unit instead of top level deployment unit

by Ori Kremer (JIRA)

Ori Kremer created AS7-4647: ------------------------------- Summary: JSF Version retrieved from deployment unit instead of top level deployment unit Key: AS7-4647 URL: https://issues.jboss.org/browse/AS7-4647 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.1.Final Reporter: Ori Kremer Assignee: Remy Maucherat In org.jboss.as.web.SharedTldsMetaDataBuilder the JSF version is retrieved from the deployment unit. When processing deployment, the JSF version is stored on the top level deployment therefore the same top level unit should be used to retrieve the version. -- 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 months

2
1
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 April 2012