[JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport is not portable across different JMS providers.
by Darran Lofthouse (JIRA)
JMSTransportSupport is not portable across different JMS providers.
-------------------------------------------------------------------
Key: JBAS-3630
URL: http://jira.jboss.com/jira/browse/JBAS-3630
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.4.GA
Reporter: Darran Lofthouse
Assigned To: Thomas Diesler
Fix For: JBossAS-4.0.6.CR1
JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
String fromName = null;
Destination destination = message.getJMSDestination();
if (destination instanceof Queue)
fromName = "queue/" + ((Queue)destination).getQueueName();
if (destination instanceof Topic)
fromName = "topic/" + ((Topic)destination).getTopicName();
For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBAS-5745) ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly
by Takayoshi Kimura (JIRA)
ServerMBean.InShutdown flag won't turn on when the shutdown hook is called directly
-----------------------------------------------------------------------------------
Key: JBAS-5745
URL: http://jira.jboss.com/jira/browse/JBAS-5745
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: System service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Takayoshi Kimura
Assigned To: Dimitris Andreadis
The ServerMBean.InShutdown flag is only turned on when the shutdown() operation is called. There is another shutdown path, a shutdown hook called by signals including Ctrl+c. This flag is needed to update in the shutdownHook.shutdown() method to reflect the sever status.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBAS-5554) Cross-cluster dependencies
by Brian Stansberry (JIRA)
Cross-cluster dependencies
--------------------------
Key: JBAS-5554
URL: http://jira.jboss.com/jira/browse/JBAS-5554
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Clustering, Deployers
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Service B on node 2 depends on Service A on node 1.
Per Scott, "Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation."
This also ties in with the coordinated deployment issue in JBAS-5553, as we wouldn't want Service B deployment to fail on node 2 just because it happened to deploy before Service A on node 1.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBAS-5102) Crossreferencing EJBs using comp-names does not work
by Christian Nolte (JIRA)
Crossreferencing EJBs using comp-names does not work
----------------------------------------------------
Key: JBAS-5102
URL: http://jira.jboss.com/jira/browse/JBAS-5102
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA
Reporter: Christian Nolte
Assigned To: Carlo de Wolf
I have two stateless session beans which are referencing each other like
that:
@Stateless
public class SessionBeanA implements SessionBeanALocal {
@EJB private SessionBeanB sessionB;
}
and
@Stateless
public class SessionBeanB implement SessionBeanBLocal {
@EJB private SessionBeanA sessionA;
}
When deploying the application on JBoss AS I get
--- MBeans waiting for other MBeans ---
ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
persistence.units:jar=test.jar,unitName=test.jar
Depends On Me:
jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
Depends On Me:
jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3
and the deployment fails.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBAS-5197) Add "RetryInterceptor" functionality to all clustered proxies
by Brian Stansberry (JIRA)
Add "RetryInterceptor" functionality to all clustered proxies
-------------------------------------------------------------
Key: JBAS-5197
URL: http://jira.jboss.com/jira/browse/JBAS-5197
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.1.0.CR1
Container issue for ensuring "RetryInterceptor" functionality is added to all clustered proxies.
"RetryInterceptor" functionality consists of adding an interceptor that is able to access the cluster (currently via JNDI) and get an updated set of cluster targets when all current targets have failed. Needed when a complete cluster restart has occurred since the current list of targets was deserialized on the client.
We currently have this for EJB2 proxies; need it for EJB3, HA-JNDI and generic AOP-based and ProxyFactoryHA-based proxies.
--
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
15 years, 1 month