September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-2125) Non public timeouts method invocations fail for EJB3 beans

by jaikiran pai (JIRA)

Non public timeouts method invocations fail for EJB3 beans ---------------------------------------------------------- Key: EJBTHREE-2125 URL: https://jira.jboss.org/browse/EJBTHREE-2125 Project: EJB 3.0 Issue Type: Bug Components: core Affects Versions: EJB3_1 1.0.7 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: EJB3_1 1.0.8 As mentioned in EJBTHREE-1733: <quote> Another bug - private timeout methods on the bean aren't invoked by the timerservice impl. The spec allows for such invocations: EJB3.1 Spec, 18.2.5.3: A timeout callback method can have public, private, protected, or package level access. A timeout callback method must not be declared as final or static. </quote> Creating this new JIRA for tracking this specific issue separately. -- 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

15 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2143) EjbResolver must support no-interface view lookup

by Marius Bogoevici (JIRA)

EjbResolver must support no-interface view lookup ------------------------------------------------- Key: EJBTHREE-2143 URL: https://jira.jboss.org/browse/EJBTHREE-2143 Project: EJB 3.0 Issue Type: Bug Components: nointerface Reporter: Marius Bogoevici It currently works only if the bean has an interface. -- 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

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2138) TimeoutMethodCallbackRequirements doesn't take into account the timeout method parameters

by jaikiran pai (JIRA)

TimeoutMethodCallbackRequirements doesn't take into account the timeout method parameters ----------------------------------------------------------------------------------------- Key: EJBTHREE-2138 URL: https://jira.jboss.org/browse/EJBTHREE-2138 Project: EJB 3.0 Issue Type: Bug Components: timeout Affects Versions: bom-eap5-0.1.2, EJB3_1 1.0.7 Reporter: jaikiran pai Assignee: jaikiran pai Consider the following base class: public class Base { protected void onTimeout() { ... } } and a EJB impl class which extends it: @Stateless public class Bean extends Base { protected void onTimeout(Timer timer) { // This one should *not* be picked up, based on the ejb-jar.xml } } and the corresponding ejb-jar.xml which marks the onTimeout() method (the one in Base class without any params) as the timeout callback method: <timeout> <method-name>onTimeout</method-name> <method-params> </method-params> </timeout> Based on this configuration and code, the Base.onTimeout() method must be chosen as the timeout callback method, but because of the lack of information of method param types, the TimeoutMethodCallbackRequirements, incorrectly, ends up picking the Bean.onTimeout(Timer timer) method as the timeout callback method. -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2592) Documentation: large images should scale to print for PDF output

by Geoffrey De Smet (JIRA)

Documentation: large images should scale to print for PDF output ---------------------------------------------------------------- Key: JBRULES-2592 URL: https://jira.jboss.org/browse/JBRULES-2592 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.1.0.CR1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.1.0.FINAL might have something to do with the width="100%" trick. Wondering if the jboss.org style can't handle this problem for us? In any case the drools planner pdf of the example screenshots looks terrible (similar problems in flow etc) -- 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

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2661) Patch to fix drools-docs build for jdocbook 2.3.0

by John Casey (JIRA)

Patch to fix drools-docs build for jdocbook 2.3.0 ------------------------------------------------- Key: JBRULES-2661 URL: https://jira.jboss.org/browse/JBRULES-2661 Project: Drools Issue Type: Patch Security Level: Public (Everyone can see) Components: drools-docs Affects Versions: 5.1.0.FINAL Reporter: John Casey Assignee: Mark Proctor Version 2.3.0 of the maven-jdocbook-plugin can't be used as-is because of http://jira.codehaus.org/browse/MNG-4761. The issue is detailed here: https://jira.jboss.org/browse/MPJDOCBOOK-59. As a temporary fix, you can set the scope of the plugin-level dependencies explicitly using the attached patch. I've tested this against the trunk (revId 34607). -- 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

15 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2594) runExamples.bat has errors

by Wise Guy (JIRA)

runExamples.bat has errors -------------------------- Key: JBRULES-2594 URL: https://jira.jboss.org/browse/JBRULES-2594 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.1.0.CR1 Environment: Windows Reporter: Wise Guy Assignee: Mark Proctor Priority: Minor The runExamples.bat file from drools-5.1.0.CR1-planner.zip has errors when run. Line 14 starts with "#" instead of "rem" and line 15 has the JVM option "-server" which in case of JRE returns "Error: no `server' JVM at" -- 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

15 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-7666) Datasource wrapper returns same java.sql.Connection object to multiple threads in multithreaded environment

by Smita Nimbalkar (JIRA)

Datasource wrapper returns same java.sql.Connection object to multiple threads in multithreaded environment ------------------------------------------------------------------------------------------------------------ Key: JBAS-7666 URL: https://jira.jboss.org/jira/browse/JBAS-7666 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Environment: JBoss Version: jboss-5.1.0.GA, OS: Linux (2.6.18-164.el5), Architecture: amd64 64bit, JVM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16, mixed mode) Reporter: Smita Nimbalkar Sometimes this happens that in multithreaded environment Datasource wrapper returns same java.sql.Connection object from connection pool to different threads. Test case scenario: There are multiple threads which needs java.sql.Connection object. If one thread has reference to java.sql.Connection then when other thread requests connection then it gets reference to same java.sql.Connection object that means two threads has reference to same connection object from the pool. If one thread closes this connection first and then other thread tries to do any operation on connection object then we get following exception: Caused by: java.lang.IllegalAccessException: Failed to find connection: 14271357 at org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService.invoke(WrapperDataSourceService.java:212) at sun.reflect.GeneratedMethodAccessor281.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422) at sun.reflect.GeneratedMethodAccessor283.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) ... 17 more -- 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

15 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-7703) org.jboss.test.web.test.JSPAnnotationENCUnitTestCase.testSimpleEjbJSPAnnotations

by Brian Stansberry (JIRA)

org.jboss.test.web.test.JSPAnnotationENCUnitTestCase.testSimpleEjbJSPAnnotations -------------------------------------------------------------------------------- Key: JBAS-7703 URL: https://jira.jboss.org/jira/browse/JBAS-7703 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 Test case is failing because of a problem in the ENC mapping to global JNDI. Test deploys a JSP with the following field: @EJB private SimpleStateless simpleStateless; Populating the field results in an exception with the following critical part: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: SimpleStatelessBean not bound] org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1356) org.jnp.interfaces.NamingContext.lookup(NamingContext.java:819) org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) org.jboss.ejb3.JndiUtil.lookup(JndiUtil.java:44) org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:75) org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:99) org.jboss.web.tomcat.service.TomcatInjectionContainer.processInjectors(TomcatInjectionContainer.java:391) org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:445) org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:407) org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:290) org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:281) org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:253) javax.servlet.http.HttpServlet.service(HttpServlet.java:847) The ENC contains a LinkRef of type LinkAddress, content SimpleStatelessBean. Problem is "SimpleStatelessBean" does not match the global JNDI namespace binding for the EJB. The EJB is contained in a jbosstest-jsp-injection.ear and the global JNDI namespace bindings for the EJB are: +- jbosstest-jsp-injection (class: org.jnp.interfaces.NamingContext) | +- SimpleStatelessBean (class: org.jnp.interfaces.NamingContext) | | +- local-org.jboss.test.web.ejb3.SimpleLocal (class: Proxy for: org.jboss.test.web.ejb3.SimpleLocal) | | +- local (class: Proxy for: org.jboss.test.web.ejb3.SimpleLocal) | | +- remote (class: Proxy for: org.jboss.test.web.ejb3.SimpleStateless) | | +- remote-org.jboss.test.web.ejb3.SimpleStateless (class: Proxy for: org.jboss.test.web.ejb3.SimpleStateless) -- 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

15 years, 8 months

4
15
0 / 0

[JBoss JIRA] Created: (GPD-400) Designer removes <java> tags from <on> tags

by Tamas Malatinszki (JIRA)

Designer removes <java> tags from <on> tags ------------------------------------------- Key: GPD-400 URL: https://jira.jboss.org/browse/GPD-400 Project: jBPM GPD Issue Type: Bug Affects Versions: jBPM jPDL Designer 4.0.0.GA Environment: Windows XP, Eclipse 3.5.2 Reporter: Tamas Malatinszki Assignee: Koen Aers Original XML file: <mail g="348,588,169,53" name="Notification" template="mailtemplate"> <on event="start"> <java class="com.own.jbpm.Notifications" method="licenseChecking" var="mail"> <arg><object expr="#{processId}"/></arg> </java> </on> <transition g="7,-8" name="Waiting for license" to="Waiting for license requirements" /> </mail> After any modification on Diagram view: <mail g="348,588,169,53" name="Notification" template="mailtemplate"> <on event="start"> </on> <transition g="7,-8" name="Waiting for license" to="Waiting for license requirements" /> </mail> Issue is seems similar to GPD-395. -- 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

15 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2682) ServiceRegistryImpl is registered twice: once as a singleton and once as a service tracker

by Antoine Toulme (JIRA)

ServiceRegistryImpl is registered twice: once as a singleton and once as a service tracker ------------------------------------------------------------------------------------------ Key: JBRULES-2682 URL: https://jira.jboss.org/browse/JBRULES-2682 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.2.0.M1 Reporter: Antoine Toulme Assignee: Mark Proctor Fix For: FUTURE Attachments: ServiceRegistryImpl.patch This bug occurs when using Drools inside an OSGi environment. The ServiceRegistryImpl is instantiated instead of using the instance singleton, which leads to having objects being registered against the wrong ServiceRegistry. The OSGi class loader won't let the default instantiator work, as the classes are part of a different bundle. As a result, the configuration of the knowledge base fails. The patch attached fixes this problem, it is a one liner. -- 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

15 years, 8 months

1
2
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 September 2010