October 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3241) Behavior of data in maps is broken/erratic

by Zachary St Lawrence (Created) (JIRA)

Behavior of data in maps is broken/erratic ------------------------------------------ Key: JBRULES-3241 URL: https://issues.jboss.org/browse/JBRULES-3241 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.3.0.CR1, 5.2.0.Final, 5.4.0.Beta1 Environment: Ubuntu 4.4.3-4ubuntu5 64 bit openjdk jvm Tested on 5.2.Final and 5.4.nightlybuild on hudson Reporter: Zachary St Lawrence Assignee: Mark Proctor Map accessors have been improved in 5.4 but there are still at least a half dozen cases that are broken. They were basically unusable in 5.2. Create a Map<KeyEnum, ValueEnum> on an object and try to access it. In 5.2 you can not access directly via the map object. In 5.4 you can access if KeyEnum was an externally defined enum but inner static KeyEnum will cause errors. Created a simple project (extension of hello world Message example to demonstrate. Note that each issue I found caused the rules file to not compile so I commented out all the error lines but as they are fixed they could be commented back in to test regressions. I will try to attach files after creating this issue but if I find I do not have sufficient JIRA permissions to add the files I will add the text as comments. -- 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

12 years, 8 months

7
6
0 / 0

[JBoss JIRA] Created: (JBLOGGING-72) Debug log lines numbers are incorrect

by Hardy Ferentschik (JIRA)

Debug log lines numbers are incorrect ------------------------------------- Key: JBLOGGING-72 URL: https://issues.jboss.org/browse/JBLOGGING-72 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.GA Reporter: Hardy Ferentschik Assignee: David Lloyd Priority: Critical In Hibernate we switched to JBoss logging. Looking at the debug log we get for example: {noformat} 11:20:06,528 (main) DEBUG ConfigContext:1269 - Setting Lucene compatibility to Version LUCENE_CURRENT 11:20:06,529 (main) DEBUG ConfigContext:1554 - Using default similarity implementation: org.apache.lucene.search.DefaultSimilarity 11:20:06,529 (main) DEBUG LuceneIndexingParameters:1559 - Set index writer parameter max_buffered_docs to value : 1000 11:20:06,529 (main) DEBUG LuceneIndexingParameters:1559 - Set index writer parameter merge_factor to value : 100 11:20:06,529 (main) DEBUG WorkspaceFactory:1549 - Starting workspace for index numeric_field_test using an exclusive index strategy 11:20:06,530 (main) INFO AvroSerializationProvider:73 - HSEARCH000079: Serialization protocol version 1.0 11:20:06,535 (main) DEBUG DocumentBuilderIndexedEntity:1559 - Field selection in projections is set to true for entity org.hibernate.search.test.engine.PinPoint. 11:20:06,536 (main) DEBUG DocumentBuilderIndexedEntity:1559 - Field selection in projections is set to true for entity org.hibernate.search.test.engine.Location. 11:20:06,537 (main) DEBUG FullTextIndexEventListener:1269 - Hibernate Search event listeners activated 11:20:06,537 (main) DEBUG FullTextIndexEventListener:1269 - Hibernate Search dirty checks enabled {noformat} The lines numbers for the debug trace are wrong and in most cases exceed even the actual line numbers in the corresponding file -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

9
10
0 / 0

[JBoss JIRA] Created: (LOGTOOL-29) The tooling does not properly implement the @FormatWith annotation

by James Perkins (JIRA)

The tooling does not properly implement the @FormatWith annotation ------------------------------------------------------------------ Key: LOGTOOL-29 URL: https://issues.jboss.org/browse/LOGTOOL-29 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: James Perkins Fix For: 1.0.0.Beta9 The equals on line 67 of the ParameterFactory does not work correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (JBLOGGING-52) Use of system property for proxy generation setting is too inflexible

by Dan Allen (JIRA)

Use of system property for proxy generation setting is too inflexible --------------------------------------------------------------------- Key: JBLOGGING-52 URL: https://issues.jboss.org/browse/JBLOGGING-52 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-spi Affects Versions: 3.0.0.Beta4-jboss-logging Reporter: Dan Allen Assignee: David Lloyd Fix For: 3.0.0.Beta5-jboss-logging JBoss Logging uses a system property to configure whether or not proxies are generated for type-safe loggers. This approach is very inflexible. The main issue is that the value of this system property is being cached too aggressively. In CDI extensions, we are forced to use a static code block to set the property so it is assigned early enough that JBoss Logging caches the correct value. However, with multiple extensions loading in a non-deterministic order, we end up having to put this static block in multiple places. [1] We need a better way to apply this setting. Perhaps a static method on a configuration API to assign the value before any logging takes place. [1] https://github.com/seam/solder/blob/master/impl/src/main/java/org/jboss/s... https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
12
0 / 0

[JBoss JIRA] (JBRULES-3255) inserting fact before populating rule base => rule does not fire, because of eval()

by Jean-Marc Vanel (Created) (JIRA)

inserting fact before populating rule base => rule does not fire, because of eval() ------------------------------------------------------------------------------------ Key: JBRULES-3255 URL: https://issues.jboss.org/browse/JBRULES-3255 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: FUTURE Reporter: Jean-Marc Vanel Assignee: Mark Proctor Scenario : * populate a working memory while the rule base is empty; * then populate the rule base ; * then fire rules * ==> rules should actually fire. It works for most cases, BUT when the LHS has an eval like this it fails: when Triple( subject == "<a>" , $x : object ) eval( Double.parseDouble( $x ) > 5 ) -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AS7-2129) CLONE - Endpoint address in generated WSDL doesn't reflect IP address of AS7 server, it's always localhost

by Rostislav Svoboda (Created) (JIRA)

CLONE - Endpoint address in generated WSDL doesn't reflect IP address of AS7 server, it's always localhost ---------------------------------------------------------------------------------------------------------- Key: AS7-2129 URL: https://issues.jboss.org/browse/AS7-2129 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.1.0.Alpha1 Reporter: Rostislav Svoboda Assignee: Alessio Soldano Priority: Critical Endpoint address in generated WSDL doesn't reflect IP address of AS7 server. It's always set to localhost, when I tried to deploy the same archive on EAP 5.1.1 the address was correct (10.34.3.154 in my case). Steps to reproduce: Run latest AS7 build on your public IP address: {code} bin/standalone.sh --server-config=standalone.xml -b=10.34.3.154 -bmanagement=10.34.3.154 {code} Deploy jaxws-benchmark-datatypes-ejb3.jar from WS testsuite Check http://10.34.3.154:8080/jaxws-benchmark-datatypes-ejb3/EndpointEJB3Wrappe... {code} ... <wsdl:service name="EndpointWrappedDocService"> <wsdl:port binding="tns:EndpointWrappedDocServiceSoapBinding" name="EndpointWrappedDocPort"> <soap:address location="http://localhost:8080/jaxws-benchmark-datatypes-ejb3/EndpointWrappedDocSe..."/> </wsdl:port> </wsdl:service> {code} -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (AS7-1794) urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, aplication-policy is not available

by Karel Piwko (JIRA)

urn:jboss:pojo:7.0 is a subset of *-jboss-beans.xml, aplication-policy is not available --------------------------------------------------------------------------------------- Key: AS7-1794 URL: https://issues.jboss.org/browse/AS7-1794 Project: Application Server 7 Issue Type: Bug Environment: AS 7.1.0-Alpha1-SNAPSHOT - commit 335c262c7449e4f6667b5339838bfdf0a65f5263 Reporter: Karel Piwko I'm migrating an application which has security domain defined in *-jboss-beans.xml from AS 5 to AS 7. {code:xml} <?xml version="1.0" encoding="UTF-8"?> <deployment xmlns="urn:jboss:pojo:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd"> <application-policy name="security-preauth"> <authentication> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="usersProperties" value="security-preauth-users.properties" /> <module-option name="rolesProperties" value="security-preauth-roles.properties" /> </login-module> </authentication> </application-policy> </deployment> {code} This security domain is specified in jboss-web.xml, as: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>security-preauth</security-domain> <context-root>spring-preauth</context-root> </jboss-web> {code} Here's corresponding configuration in web.xml {code:xml} <login-config> <auth-method>BASIC</auth-method> <realm-name>security-preauth</realm-name> </login-config> <security-role> <role-name>ROLE_USER</role-name> </security-role> <security-role> <role-name>ROLE_SUPERVISOR</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>All areas</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>ROLE_USER</role-name> </auth-constraint> </security-constraint> {code} This is not correctly loaded by JBoss AS, failing with (after TRACE logging is enabled): {code} 16:46:44,287 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."spring-preauth.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."spring-preauth.war".PARSE: Failed to process phase PARSE of deployment "spring-preauth.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse POJO xml ["/content/spring-preauth.war/META-INF/security-preauth-jboss-beans.xml"] at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:130) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptors(KernelDeploymentParsingProcessor.java:104) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.deploy(KernelDeploymentParsingProcessor.java:73) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT] ... 5 more Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[5,5] Message: Unexpected element '{urn:jboss:pojo:7.0}application-policy' encountered at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:65) at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:174) at org.jboss.as.pojo.descriptor.KernelDeploymentXmlDescriptorParser.readElement(KernelDeploymentXmlDescriptorParser.java:50) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59) at org.jboss.as.pojo.KernelDeploymentParsingProcessor.parseDescriptor(KernelDeploymentParsingProcessor.java:123) ... 8 more {code} Note: With AS 7.0.1 this is not working at all, *-jboss-beans.xml is ignored. Workaround is modify standalone.xml and add the security domain there, but it's not a feasible solution as it makes automated testing much harder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

6
12
0 / 0

[JBoss JIRA] (JBRULES-3242) when Guvnor repo becauses bug (over 300 MB) getting premature end of file error on webdav connection from guvnor eclipse plugin

by Nicolas Heron (Created) (JIRA)

when Guvnor repo becauses bug (over 300 MB) getting premature end of file error on webdav connection from guvnor eclipse plugin ------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-3242 URL: https://issues.jboss.org/browse/JBRULES-3242 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.3.0.CR1 Environment: Linux, Redhat, Sun JDK 64 Reporter: Nicolas Heron Assignee: Mark Proctor On the eclipse plugin, when we want to obtain the content of a package, 1) getting the following error on client side "premature end of file" 2) and on server side 14:29:56,449 INFO [STDOUT] ERROR 12-10 14:29:56,449 (WebDavServletBean.java:service:154) Exception: java.lang.NullPointerException at net.sf.webdav.methods.DoPropfind.parseProperties(DoPropfind.java:256) at net.sf.webdav.methods.DoPropfind.recursiveParseProperties(DoPropfind.java:212) at net.sf.webdav.methods.DoPropfind.recursiveParseProperties(DoPropfind.java:227) at net.sf.webdav.methods.DoPropfind.execute(DoPropfind.java:165) at net.sf.webdav.WebDavServletBean.service(WebDavServletBean.java:128) at org.drools.guvnor.server.files.WebdavServlet.service(WebdavServlet.java:73) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42) at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:65) at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:662) [Fatal Error] :1:1: Premature end of file. -- 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

12 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (AS7-1927) An EAR with 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deloyed to AS7 without any error

by Ivo Studensky (JIRA)

An EAR with 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deloyed to AS7 without any error ----------------------------------------------------------------------------------------------------------------------- Key: AS7-1927 URL: https://issues.jboss.org/browse/AS7-1927 Project: Application Server 7 Issue Type: Bug Components: EE Affects Versions: 7.1.0.Alpha1 Reporter: Ivo Studensky Assignee: David Lloyd An ear with no longer supported 'urn:jboss:bean-deployer:2.0' namespace in META-INF/jboss-beans.xml can be deployed to AS7 without any error. I tried to deploy it via command line copy and via web admin console. Both of them passed which is weird, because the same ear failed to deploy by Arquillian. If I modified the namespace to 'urn:jboss:pojo:7.0' then deployment by Arquillian passed too. It seems like META-INF/jboss-beans.xml is not fully processed if deployed by command line copy or by web admin console. Note: it was tried with the latest master of AS7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

8
9
0 / 0

[JBoss JIRA] Created: (JBAS-9316) Indentation of multiline text content in standalone.xml keeps increasing on rewrites

by David Bosschaert (JIRA)

Indentation of multiline text content in standalone.xml keeps increasing on rewrites ------------------------------------------------------------------------------------ Key: JBAS-9316 URL: https://issues.jboss.org/browse/JBAS-9316 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: XML Services/Frameworks Affects Versions: 7.0.0.Beta3 Reporter: David Bosschaert Assignee: Jason Greene Priority: Minor The standalone.xml file contains some XML tags that contain multi-line XML text, e.g.: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} The problem is that every automatic rewrite of the standalone.xml (e.g. when you deploy a new thing) the indentation increases from the 2nd line of the text, so after the first rewrite it looks like this: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} after a few deploys it ends up looking like this: {code}<property name="org.jboss.osgi.system.modules"> org.apache.log4j, org.jboss.as.osgi, javax.inject.api, ...{code} Pretty ugly :( Would be nice if the indentation could be left untouched. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

6
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2011