November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1100) local-home-jndi-name

by Shane Preater (JIRA)

local-home-jndi-name -------------------- Key: EJBTHREE-1100 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1100 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA Environment: Windows XP Reporter: Shane Preater jboss.xml version 3.0 local-home-jndi-name does not work as expected. The proxy which ends up deployed under the given name is actually the local interface not the local home interface. Code to reproduce: Remote bean: public class RemoteHomeTestEJB implements SessionBean { private SessionContext context = null; /* * (non-Javadoc) * * @see javax.ejb.SessionBean#ejbActivate() */ public void ejbActivate() throws EJBException, RemoteException { // TODO Auto-generated method stub } /* * (non-Javadoc) * * @see javax.ejb.SessionBean#ejbPassivate() */ public void ejbPassivate() throws EJBException, RemoteException { // TODO Auto-generated method stub } /* * (non-Javadoc) * * @see javax.ejb.SessionBean#ejbRemove() */ public void ejbRemove() throws EJBException, RemoteException { // TODO Auto-generated method stub } public void ejbCreate() { //Do nothing. } /* * (non-Javadoc) * * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext) */ public void setSessionContext(SessionContext ctx) throws EJBException, RemoteException { context = ctx; } public String getHello() { try { LocalHomeTestHome home = null; home = ServiceLocator.locateHome(LocalHomeTestHome.class, "java:comp/env/local/LocalHomeTest"); return home.create().getHello(); } catch (Exception e) { StringWriter stringWriter = new StringWriter(); PrintWriter writer = new PrintWriter(stringWriter); e.printStackTrace(writer); return stringWriter.toString(); } } } ServiceLocater.java: public class ServiceLocator { private static final Logger LOG = Logger.getLogger(ServiceLocator.class); @SuppressWarnings("unchecked") public static <T> T locateHome(Class<T> clazz, String location) throws NamingException { T home = null; Context ic = new InitialContext(); Object potentialHome = ic.lookup(location); if (clazz.isInstance(potentialHome)) { home = (T) potentialHome; } else { home = (T) PortableRemoteObject.narrow(potentialHome, clazz); } return home; } } Local bean: public class LocalHomeTestEJB implements SessionBean { /* (non-Javadoc) * @see javax.ejb.SessionBean#ejbActivate() */ public void ejbActivate() throws EJBException, RemoteException { // TODO Auto-generated method stub } /* (non-Javadoc) * @see javax.ejb.SessionBean#ejbPassivate() */ public void ejbPassivate() throws EJBException, RemoteException { // TODO Auto-generated method stub } public void ejbCreate() { //Do nothing. } /* (non-Javadoc) * @see javax.ejb.SessionBean#ejbRemove() */ public void ejbRemove() throws EJBException, RemoteException { // TODO Auto-generated method stub } /* (non-Javadoc) * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext) */ public void setSessionContext(SessionContext ctx) throws EJBException, RemoteException { // TODO Auto-generated method stub } public String getHello() { return "Hello from Aerosystems"; } } ejb-jar.xml: <ejb-jar version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> <description>Simple migration testing to see how to move to EJB 3</description> <display-name>EjbMigration</display-name> <enterprise-beans> <session> <description><![CDATA[EcardGenerationFacadeSessionEJB Bean]]></description> <display-name>LocalHomeTest</display-name> <ejb-name>LocalHomeTest</ejb-name> <remote>com.aeroint.ejbtest.common.RemoteHomeTestInterface</remote> <local-home>com.aeroint.ejbtest.server.session.LocalHomeTestHome</local-home> <local>com.aeroint.ejbtest.server.session.LocalHomeTestInterface</local> <ejb-class>com.aeroint.ejbtest.server.session.LocalHomeTestEJB</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <session> <description><![CDATA[EcardUpdateFacadeSessionEJB Bean]]></description> <display-name>RemoteHomeTest</display-name> <ejb-name>RemoteHomeTest</ejb-name> <home>com.aeroint.ejbtest.common.RemoteHomeTestHome</home> <remote>com.aeroint.ejbtest.common.RemoteHomeTestInterface</remote> <ejb-class>com.aeroint.ejbtest.server.facade.RemoteHomeTestEJB</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <ejb-local-ref > <ejb-ref-name>local/LocalHomeTest</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local-home>com.aeroint.ejbtest.server.session.LocalHomeTestHome</local-home> <local>com.aeroint.ejbtest.server.session.LocalHomeTestInterface</local> <ejb-link>LocalHomeTest</ejb-link> </ejb-local-ref> </session> </enterprise-beans> </ejb-jar> jboss.xml: <jboss xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd" version="3.0"> <enterprise-beans> <session> <ejb-name>RemoteHomeTest</ejb-name> <home-jndi-name>remote/RemoteHomeTest</home-jndi-name> </session> <session> <ejb-name>LocalHomeTest</ejb-name> <local-home-jndi-name>local/LocalHomeTest</local-home-jndi-name> </session> </enterprise-beans> </jboss> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBFORUMS-255) Arrows in admin page are displayed wrongly

by Ryszard Kozmik (JIRA)

Arrows in admin page are displayed wrongly ------------------------------------------ Key: JBFORUMS-255 URL: http://jira.jboss.com/jira/browse/JBFORUMS-255 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Reporter: Ryszard Kozmik Priority: Minor Fix For: 1.0.1 RC, 1.1.0 Alpha Arrows for changing order of forums and categories are messed up after admin panel view refactoring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-675) Problems with Servlet invoker

by Tom Elrod (JIRA)

Problems with Servlet invoker ----------------------------- Key: JBREM-675 URL: http://jira.jboss.com/jira/browse/JBREM-675 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Attachments: ServletServerInvoker.java Several problems with servlet invoker: 1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java 2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-838) allow user to set content-type for http responses (part 2: ServletServerInvoker)

by Ron Sigal (JIRA)

allow user to set content-type for http responses (part 2: ServletServerInvoker) -------------------------------------------------------------------------------- Key: JBREM-838 URL: http://jira.jboss.com/jira/browse/JBREM-838 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.GA Reporter: Tom Elrod Assigned To: Ron Sigal Fix For: 2.2.2.SP1 Currently the CoyoteInvoker.versionedWrite() method will set the content type of the http response by using WebUtil.getContentType(responseObject) to identify the content type based on the response object type being sent back to client. Should allow this to be overriden by the user in the same way the response code/message can be (using the response map). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
3
0 / 0

[JBoss JIRA] Closed: (JBREM-475) Eliminate ShutdownRequestThread in MultiplexingManager.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-475?page=all ] Ron Sigal closed JBREM-475. --------------------------- Resolution: Won't Fix See JBREM-842 "Deprecate multiplex transport". > Eliminate ShutdownRequestThread in MultiplexingManager. > ------------------------------------------------------- > > Key: JBREM-475 > URL: http://jira.jboss.com/jira/browse/JBREM-475 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.Beta1 (Pinto) > > > When a MultiplexingManager is requesting permission from its remote counterpart to shut down, it periodically creates a ShutdownRequestThread to send a request permission message and wait for a response. It shoud be possible to handle the waiting on the pending action thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1207) Investigate failures in StateTransferUnderLoadTest

by Manik Surtani (JIRA)

Investigate failures in StateTransferUnderLoadTest -------------------------------------------------- Key: JBCACHE-1207 URL: http://jira.jboss.com/jira/browse/JBCACHE-1207 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Vladimir Blagojevic Fix For: 2.1.0.GA This involves attempting to transfer state while having several concurrent put operations that *seem* to result in: 1) A block being issued 2) The put operation holding locks on the state generator 3) The put not being able to complete because of the block 4) The state transfer not being able to generate state because of the put operation 5) Deadlock! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-615) UDP: JGroups always allocates the same ports

by Bela Ban (JIRA)

UDP: JGroups always allocates the same ports -------------------------------------------- Key: JGRP-615 URL: http://jira.jboss.com/jira/browse/JGRP-615 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5.2, 2.6 In 2.5 and 2.6, JGroups always allocates the same ports with UDP and no bind_port set. This is different from 2.4, where different (increasing) ports were used. Investigate why this is the case, and what changed between 2.4 and 2.5. This doesn't happen on Windows and macOS, just on Linux. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4689) Upgrade JBoss messaging to 1.4.0.GA

by Dimitris Andreadis (JIRA)

Upgrade JBoss messaging to 1.4.0.GA ----------------------------------- Key: JBAS-4689 URL: http://jira.jboss.com/jira/browse/JBAS-4689 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JB5-Messaging Reporter: Dimitris Andreadis Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.Beta3 We are currently at 1.4.0.CR2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1018) Possibly fix timeout due to bug in remoting that may allow clients to hang forever.

by Jay Howell (JIRA)

Possibly fix timeout due to bug in remoting that may allow clients to hang forever. ----------------------------------------------------------------------------------- Key: JBMESSAGING-1018 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1018 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Remoting Affects Versions: 1.3.0.GA Reporter: Jay Howell Assigned To: Tim Fox This goes back to JBMESSAGING-171, when we changed the timeout on the bisocket to 0. That would have meant that it would wait forever which is what we want. There is now a bug in remoting that if this is set to 0 and the client is unreachable, then it is possible that it will hang. We may have one case of this now, but it is still unverified. The remoting bug is JBREM-767. This is fixed in the 2.4 beta of remoting, but it may present a problem before we can integrate that version in. We may want to consider changing this to a high number, so it doesn't timeout easily, but so it will timeout. Just want to put it up for concideration. The other route is to get the remoting team to put out another sp version with. They could put it in 2.2.0.SP4_CP02, but that will only go out as part of the Platform 4.2 CR release, so we may want to ask them to put it out as an 2.2.0SP5, so it will go into general population where Messaging has alot of customers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-357) Update design documentation

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-357?page=all ] Tim Fox updated JBMESSAGING-357: -------------------------------- Summary: Update design documentation (was: Update the Messaging Core documentation) Fix Version/s: 2.0.0 Beta (was: Unscheduled) Description: Make sure design documentation for JBM 2 exists and is up to date. All areas of design should be documentated. Priority: Major (was: Minor) > Update design documentation > --------------------------- > > Key: JBMESSAGING-357 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-357 > Project: JBoss Messaging > Issue Type: Task > Components: Documentation and Training > Reporter: Ovidiu Feodorov > Fix For: 2.0.0 Beta > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Make sure design documentation for JBM 2 exists and is up to date. > All areas of design should be documentated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007