March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4017) EjbClientContextSetupProcessor uses ServiceRegistry.getService()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4017?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4017: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1156620|https://bugzilla.redhat.com/show_bug.cgi?id=1156620] from MODIFIED to ON_QA > EjbClientContextSetupProcessor uses ServiceRegistry.getService() > ---------------------------------------------------------------- > > Key: WFLY-4017 > URL: https://issues.jboss.org/browse/WFLY-4017 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > As no dependencies are in place there is no guarantee this service will exist. If a deployment is present at boot time it is possible that this will not be setup correctly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4016) Memory leak on undeploy caused by ejb client

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4016?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4016: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1156620|https://bugzilla.redhat.com/show_bug.cgi?id=1156620] from MODIFIED to ON_QA > Memory leak on undeploy caused by ejb client > -------------------------------------------- > > Key: WFLY-4016 > URL: https://issues.jboss.org/browse/WFLY-4016 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > EJB client application deployed with jboss-ejb-client.xml, when undeployed the classloader is not being released leading to a memory leak. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4406) Undertow which uses ECJ 4.4.1 Compiler crash with ArrayIndexOutOfBoundsException when there is unused double or long

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4406?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4406: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1199000|https://bugzilla.redhat.com/show_bug.cgi?id=1199000] from MODIFIED to ON_QA > Undertow which uses ECJ 4.4.1 Compiler crash with ArrayIndexOutOfBoundsException when there is unused double or long > -------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4406 > URL: https://issues.jboss.org/browse/WFLY-4406 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ECJ compiler crashes with ArrayIndexOutOfBoundsException when it contains unused long or double, for details see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=448112]. > Note: this issue is fixed in ECJ 4.4.2. > The error log: > {noformat} > 11:19:49,861 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jsp-cast-to-double-test/cast-to-double.jsp: org.apache.jasper.JasperException: JBWEB004001: Unable to compile class for JSP > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:616) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:769) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 > at org.eclipse.jdt.internal.compiler.codegen.StackMapFrame.addStackItem(StackMapFrame.java:92) > at org.eclipse.jdt.internal.compiler.ClassFile.traverse(ClassFile.java:5546) > at org.eclipse.jdt.internal.compiler.ClassFile.generateStackMapTableAttribute(ClassFile.java:4305) > at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttribute(ClassFile.java:1380) > at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:338) > at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:270) > at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:566) > at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:635) > at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:368) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:781) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:470) > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:449) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) > ... 32 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4428) Upgrade to Hibernate Search 5.1.1.Final, Apache Lucene 4.10.4

by Sanne Grinovero (JIRA)

Sanne Grinovero created WFLY-4428: ------------------------------------- Summary: Upgrade to Hibernate Search 5.1.1.Final, Apache Lucene 4.10.4 Key: WFLY-4428 URL: https://issues.jboss.org/browse/WFLY-4428 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-739) BatchExecutionCommand interface does not contain setLookup() as documented

by Brad K. (JIRA)

Brad K. created DROOLS-739: ------------------------------ Summary: BatchExecutionCommand interface does not contain setLookup() as documented Key: DROOLS-739 URL: https://issues.jboss.org/browse/DROOLS-739 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 6.2.0.Final Environment: Windows 10 Preview, NetBeans 8.0.2, Java 1.7.u75 Reporter: Brad K. Assignee: Edson Tirelli Priority: Minor http://docs.jboss.org/drools/release/6.2.0.Final/drools-docs/html/ch09.ht... describes usage of BatchExecutionCommand (BEC) as {quote}BatchExecutionCommand command = new BatchExecutionCommand(); command.setLookup("ksession1"); InsertObjectCommand insertObjectCommand = new InsertObjectCommand(new Person("john", 25)); FireAllRulesCommand fireAllRulesCommand = new FireAllRulesCommand(); command.getCommands().add(insertObjectCommand); command.getCommands().add(fireAllRulesCommand);{quote} However, the BEC interface appears to be a tag-only interface with no abstract methods. The BatchExecutionCommandImpl, however, does have methods, but there are no corresponding methods in the BEC. Either the documentation is incorrect or the BEC interface is incorrect. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-739) BatchExecutionCommand interface does not contain setLookup() as documented

by Brad K. (JIRA)

[ https://issues.jboss.org/browse/DROOLS-739?page=com.atlassian.jira.plugin... ] Brad K. updated DROOLS-739: --------------------------- Workaround Description: Use BatchExecutionCommandImpl and ignore the BatchExecutionCommand interface. (was: Use BatchExecutionCommandImpl and ignore the BatchExecutionInterface.) > BatchExecutionCommand interface does not contain setLookup() as documented > -------------------------------------------------------------------------- > > Key: DROOLS-739 > URL: https://issues.jboss.org/browse/DROOLS-739 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.2.0.Final > Environment: Windows 10 Preview, NetBeans 8.0.2, Java 1.7.u75 > Reporter: Brad K. > Assignee: Edson Tirelli > Priority: Minor > > http://docs.jboss.org/drools/release/6.2.0.Final/drools-docs/html/ch09.ht... describes usage of BatchExecutionCommand (BEC) as > {quote}BatchExecutionCommand command = new BatchExecutionCommand(); > command.setLookup("ksession1"); > InsertObjectCommand insertObjectCommand = new InsertObjectCommand(new Person("john", 25)); > FireAllRulesCommand fireAllRulesCommand = new FireAllRulesCommand(); > command.getCommands().add(insertObjectCommand); > command.getCommands().add(fireAllRulesCommand);{quote} > However, the BEC interface appears to be a tag-only interface with no abstract methods. The BatchExecutionCommandImpl, however, does have methods, but there are no corresponding methods in the BEC. Either the documentation is incorrect or the BEC interface is incorrect. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.

by Takashi Nishigaya (JIRA)

[ https://issues.jboss.org/browse/WFLY-4427?page=com.atlassian.jira.plugin.... ] Takashi Nishigaya updated WFLY-4427: ------------------------------------ Attachment: batch-restart-failed.zip > Step status of the failed step by <fail> element becomes COMPLETED. > ------------------------------------------------------------------- > > Key: WFLY-4427 > URL: https://issues.jboss.org/browse/WFLY-4427 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Cheng Fang > Attachments: batch-restart-failed.zip > > > Assuming the following job definition, if STEP1 returns "1" as the exit status, the job status becomes FAILED. But the step status is COMPLETED. > {noformat} > job status: FAILED > step: STEP1, step status: COMPLETED > {noformat} > {noformat} > <job id="batch-job1" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd "> > <step id="STEP1"> > <batchlet ref="TestBatchlet1" /> > <next on="0" to="STEP2" /> > <fail on="1" exit-status="FAILED_BY_EXIT_STATUS" /> > </step> > <step id="STEP2"> > <batchlet ref="TestBatchlet2" /> > </step> > </job> > {noformat} > In this case, we can not restart the failed job from the failed step STEP1. > This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in JSR 352. > But it is not expected result. > {quote} > 10.8 Restart Processing > 3. Starting at the restart position, each execution element is re-examined to determine if it should re-execute: > a. If the execution element is a COMPLETED step that specifies allow-restart-if- complete=false, then follow the transition to the next > execution element based on the exit status for this step from the previous execution. > {quote} > On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting job status and the step status are FAILED. > {noformat} > job status: FAILED > step: STEP1, step status: FAILED > {noformat} > In this case, restarting the failed job is correctly executed, because the step status is FAILED. > I think the step status of the failed step should be FAILED in both cases. But the section "8.6.2 Fail Element" of JSR352 says nothing about what step status value must be exposed after failed. > This behavior is the same in GlassFish 4 and WildFly 8.2. > So, I want to know what is the correct specification or intended behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4427) Step status of the failed step by <fail> element becomes COMPLETED.

by Takashi Nishigaya (JIRA)

Takashi Nishigaya created WFLY-4427: --------------------------------------- Summary: Step status of the failed step by <fail> element becomes COMPLETED. Key: WFLY-4427 URL: https://issues.jboss.org/browse/WFLY-4427 Project: WildFly Issue Type: Bug Components: Batch Affects Versions: 8.2.0.Final Reporter: Takashi Nishigaya Assignee: Cheng Fang Assuming the following job definition, if STEP1 returns "1" as the exit status, the job status becomes FAILED. But the step status is COMPLETED. {noformat} job status: FAILED step: STEP1, step status: COMPLETED {noformat} {noformat} <job id="batch-job1" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd "> <step id="STEP1"> <batchlet ref="TestBatchlet1" /> <next on="0" to="STEP2" /> <fail on="1" exit-status="FAILED_BY_EXIT_STATUS" /> </step> <step id="STEP2"> <batchlet ref="TestBatchlet2" /> </step> </job> {noformat} In this case, we can not restart the failed job from the failed step STEP1. This behavior is correct based on the description of 10.8 Restart Processing, 3. a. in JSR 352. But it is not expected result. {quote} 10.8 Restart Processing 3. Starting at the restart position, each execution element is re-examined to determine if it should re-execute: a. If the execution element is a COMPLETED step that specifies allow-restart-if- complete=false, then follow the transition to the next execution element based on the exit status for this step from the previous execution. {quote} On the other hand, If the STEP1 is failed by throwing an exception, both of the resulting job status and the step status are FAILED. {noformat} job status: FAILED step: STEP1, step status: FAILED {noformat} In this case, restarting the failed job is correctly executed, because the step status is FAILED. I think the step status of the failed step should be FAILED in both cases. But the section "8.6.2 Fail Element" of JSR352 says nothing about what step status value must be exposed after failed. This behavior is the same in GlassFish 4 and WildFly 8.2. So, I want to know what is the correct specification or intended behavior. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-597) Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-597: --------------------------------------- Summary: Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations. Key: WFCORE-597 URL: https://issues.jboss.org/browse/WFCORE-597 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Tomaz Cerar Fix For: 1.0.0.Beta1 If an ObjectTypeAttributeDefinition contains an attribute definition that has ResourceOnly set then it should be filtered from the automatically generated description for the add operation. This may be more related to lists, I currently have: - ObjectListAttributeDefinition, which contains ObjectTypeAttributeDefinition, which contains SimpleAttributeDefinition It is this final SimpleAttributeDefinition that has ResourceOnly set but it is still showing up in the operation description for add. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4425) Adding of JMS/MDB annotations in classes of project switches off activation-call of install singleton service in cluster

by Serg Jackbean (JIRA)

[ https://issues.jboss.org/browse/WFLY-4425?page=com.atlassian.jira.plugin.... ] Serg Jackbean resolved WFLY-4425. --------------------------------- Fix Version/s: 8.2.0.Final Resolution: Done Error was caused by wrong configuration of jms queue in config xml: absent entry. by the way. what is right method of invoking methods of singletone in cluster? method getValue in example - doesn't contain any arguments > Adding of JMS/MDB annotations in classes of project switches off activation-call of install singleton service in cluster > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-4425 > URL: https://issues.jboss.org/browse/WFLY-4425 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB, JMS, MSC > Affects Versions: 8.2.0.Final > Environment: Windows. JDK 7 > Reporter: Serg Jackbean > Assignee: Paul Ferraro > Fix For: 8.2.0.Final > > > Adding of JMS/MDB annotations in classes of project switches off activation-call of install singleton service in cluster. > singleton service in cluster: > https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton > MDB classes from example: > https://blogs.oracle.com/arungupta/entry/simple_jms_2_0_sample > JMS Annotations example: > http://www.mastertheboss.com/jboss-server/jboss-jms/jms-20-tutorial-on-wi... > (by the way. what is right method of invoking methods of singletone in cluster? method getValue in example - doesn't contain any arguments) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
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 March 2015