July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1889) Duplicate messages are produced during cluster failover when a cluster node is shutdown

by Tom Ross (JIRA)

Duplicate messages are produced during cluster failover when a cluster node is shutdown --------------------------------------------------------------------------------------- Key: JBMESSAGING-1889 URL: https://issues.jboss.org/browse/JBMESSAGING-1889 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.8.SP1 Environment: JBoss EAP 5.1.1 Reporter: Tom Ross Assignee: Yong Hao Gao The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script. The following is a description of the events that hava happened that lead to duplicate messages. - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down. - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster. - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2. - node-2 redelivers the message to the MDB in a separate transaction and committs. So the message is received twice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (AS7-1349) JAX-RS sub resources broken

by Jozef Hartinger (JIRA)

JAX-RS sub resources broken --------------------------- Key: AS7-1349 URL: https://issues.jboss.org/browse/AS7-1349 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.0.0.Final Reporter: Jozef Hartinger Assignee: Stuart Douglas Priority: Critical Fix For: 7.0.1.Final Having a root resource class @Path("person") public class PeopleResource { @Path("{name}") public PersonResource findPerson(@PathParam("name") String name) { return new PersonResource(name); } } and a sub resource class public class PersonResource { private String name; public PersonResource(String name) { this.name = name; } @GET public String getName() { return name; } @GET @Path("/address") public String getClassName() { return name + "'s address is unknown."; } } The application fails with the following exception. Seems like during scanning the subresource is identified as a root resource (although it is not a root resource). Subsequently, RESTEasy's validation fails. javax.servlet.ServletException: Servlet.init() for servlet org.jboss.resteasy.cdi.test.MyApplication threw exception org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) java.lang.Thread.run(Thread.java:662) root cause java.lang.RuntimeException: Class is not a root resource. It, or one of its interfaces must be annotated with @Path: org.jboss.resteasy.cdi.test.Subresource implements: java.io.Serializable org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:104) org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83) org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72) org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:367) org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:225) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1373) Setting EJB's InjectionTarget does not work

by Jozef Hartinger (JIRA)

Setting EJB's InjectionTarget does not work ------------------------------------------- Key: AS7-1373 URL: https://issues.jboss.org/browse/AS7-1373 Project: Application Server 7 Issue Type: Bug Components: CDI / Weld Affects Versions: 7.0.0.Final Reporter: Jozef Hartinger Assignee: Stuart Douglas Priority: Blocker Fix For: 7.0.1.Final Having an EJB {code} @Singleton public class Bus { private boolean initialized = false; public boolean isInitialized() { return initialized; } public void setInitialized(boolean initialized) { this.initialized = initialized; } } {code} and a CDI extension that wraps EJB's InjectionTarget {code} public class WrappingExtension implements Extension { public void wrapInjectionTarget(@Observes ProcessInjectionTarget<Bus> event) { final InjectionTarget<Bus> injectionTarget = event.getInjectionTarget(); event.setInjectionTarget(new ForwardingInjectionTarget<Bus>() { @Override public void inject(Bus instance, CreationalContext<Bus> ctx) { super.inject(instance, ctx); instance.setInitialized(true); } @Override public InjectionTarget<Bus> getDelegate() { return injectionTarget; } }); } } {code} the InjectionTarget implementation is never invoked. When the Bus bean is changed to a CDI bean (@Singleton annotation is removed), the InjectionTarget implementation is invoked as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1385) make storeAsBinary configurable

by Michal Linhard (JIRA)

make storeAsBinary configurable ------------------------------- Key: AS7-1385 URL: https://issues.jboss.org/browse/AS7-1385 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.0.0.Final Reporter: Michal Linhard Assignee: Paul Ferraro Priority: Critical we need be able to turn on/off these infinispan config options infinispan.configuration.storeAsBinary.enabled infinispan.configuration.lazyDeserialization.enabled it's not yet known what causes performance degradation in JBPAPP-6865, but we need to be able to eliminate effect of these params -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1787) Undocumented Panels for Eclipse Guided Rule Editor

by Steve Nunez (Illation) (JIRA)

Undocumented Panels for Eclipse Guided Rule Editor -------------------------------------------------- Key: JBRULES-1787 URL: https://jira.jboss.org/jira/browse/JBRULES-1787 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.0.7 Reporter: Steve Nunez (Illation) Assignee: Mark Proctor In the Guided Rule Editor section: http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/html_single/index.h... There is an explanation of the guided editor. However there is no explanation of what to expect to see in the various tabs, except the first one. What I expect to see in the "Generated DRL (read-only)" tab is the actual DRL that will be sent to the compiler, similar to that we see in the "DRL Viewer" pane of a .dslr file. What I actually see is the same sort of text that I see in the .dslr file, with no idea if it's actually be rendered correctly (in a subsequent step). -- 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

13 years, 5 months

5
14
0 / 0

[JBoss JIRA] Created: (JBRULES-1889) figures not properly displayed in Drools Expert User Guide

by Jaroslaw Kijanowski (JIRA)

figures not properly displayed in Drools Expert User Guide ---------------------------------------------------------- Key: JBRULES-1889 URL: https://jira.jboss.org/jira/browse/JBRULES-1889 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs-expert Affects Versions: 5.0.0.M3 Reporter: Jaroslaw Kijanowski Assignee: Mark Proctor Affected figures: 1.1.; 1.4.; 1.5 -- 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

13 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3154) Date handling in XLS tables

by Michael Anstis (JIRA)

Date handling in XLS tables --------------------------- Key: JBRULES-3154 URL: https://issues.jboss.org/browse/JBRULES-3154 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Michael Anstis Assignee: Michael Anstis Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler. Example (in the repository_export.xml attached file) : * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param" * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...) Problems (at compilation and DRl generation) : * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed ! * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january") * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error). * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK. So I guess that reading dates in the XLS is the source of the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBAS-9244) @SecurityDomain doesn't work with @Singleton

by Christian Reiter (JIRA)

@SecurityDomain doesn't work with @Singleton -------------------------------------------- Key: JBAS-9244 URL: https://issues.jboss.org/browse/JBAS-9244 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.Final Environment: Windows Vista, java version "1.6.0_23" Reporter: Christian Reiter Assignee: Anil Saldhana In Jboss AS 6 (6.0.0.Final) the Annotation @SecurityDomain from the package org.jboss.ejb3.annotation.SecurityDomain doesn't seem to work with @Singleton - SessionBeans. If I try to call a method from a @Singleton which is marked with @RolesAllowed i get a "java.lang.IllegalStateException: Security Context has not been set" Exception. If I do completely the same with a @Stateless SessionBean everything works fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2245) BMT interceptor doesn't take into account application exceptions

by jaikiran pai (JIRA)

BMT interceptor doesn't take into account application exceptions ---------------------------------------------------------------- Key: EJBTHREE-2245 URL: https://issues.jboss.org/browse/EJBTHREE-2245 Project: EJB 3.0 Issue Type: Bug Components: transactions Affects Versions: 2.0.0-alpha-1 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 2.0.0-alpha-2 BMT interceptors currently don't check for application exception semantics as mandated by EJB3 spec. See EJB3.1 spec section 14.3.1, Table 16 for details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-3143) Knowledge Agent does not handle multiple packages in Builder output from single resource

by Wolfgang Laun (JIRA)

Knowledge Agent does not handle multiple packages in Builder output from single resource ---------------------------------------------------------------------------------------- Key: JBRULES-3143 URL: https://issues.jboss.org/browse/JBRULES-3143 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.Final Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Blocker Fix For: 5.2.1.Final Note: see also https://issues.jboss.org/browse/JBRULES-2940 KnowledgeAgent with a ChecngeSet containing a single DRL: package x import y.Type declare Type @role(event) end //...rules etc. If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder. =!=> KA must process all packages from the builder. =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds. =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011