[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite
by Aleksandar Kostadinov (JIRA)
Hard-coded localhost in ejb3 test suite
---------------------------------------
Key: EJBTHREE-880
URL: http://jira.jboss.com/jira/browse/EJBTHREE-880
Project: EJB 3.0
Issue Type: Bug
Reporter: Aleksandar Kostadinov
When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head.
One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem.
--
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
14 years, 1 month
[JBoss JIRA] (AS7-4004) Queue selector set in standalone-full.xml not parsed as defined in the HornetQ documentation
by A l e c C R E S T A N (JIRA)
A l e c C R E S T A N created AS7-4004:
------------------------------------------
Summary: Queue selector set in standalone-full.xml not parsed as defined in the HornetQ documentation
Key: AS7-4004
URL: https://issues.jboss.org/browse/AS7-4004
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.0.Final
Environment: Windows vista, jdk6 32b
Reporter: A l e c C R E S T A N
Assignee: Andy Taylor
HornetQ 2.2.5 documentation says in chapter 25 "Queue attributes" that JMS queue may have a selector defined:
<queue name="selectorQueue">
<entry name="/queue/selectorQueue"/>
<selector string="color='red'"/>
<durable>true</durable>
</queue>
In JBoss, a configuration with
<jms-queue name="selectorQueue">
<entry name="queue/selectorQueue"/>
<selector string="color='red'"/>
</jms-queue>
fails to start with an exception:
Message: "JBAS014704: '' is an invalid value for parameter selector. Values must have a minimum length of 1 characters"
It starts with the following structure:
<jms-queue name="selectorQueue">
<entry name="queue/selectorQueue"/>
<selector>color='red'</selector>
</jms-queue>
but the filtering of messages NEVER occurs and all messages go to the queue (all colors).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3731) Only one deployed application can use custom mailcap
by Philippe Guinot (JIRA)
Philippe Guinot created AS7-3731:
------------------------------------
Summary: Only one deployed application can use custom mailcap
Key: AS7-3731
URL: https://issues.jboss.org/browse/AS7-3731
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.1.0.CR1b
Environment: AS 7, many applications deployed with custom mailcaps.
Reporter: Philippe Guinot
Assignee: David Lloyd
Priority: Minor
In the MailcapCommandMap class, it loads the mailcap file only once. This may cause troubles when different applications use different custom mailcap.
Also, if no mailcap is found in the current class loader, only ONE mailcap file from the module will be loaded, and not all of them, which is an issue if we get the mail-dsn jar added in the javax.mail.api module.
If there is only one application deployed, adding in the jboss-deployement-structure.xml the following dependency:
{code:xml}<module name="javax.mail.api"><imports><include path="META-INF"/><include path="META-INF/**"/></imports></module>{code}
and, from the application, calling at startup:
{code}javax.activation.CommandMap.setDefaultCommandMap(new MailcapCommandMap());{code}
cause the loading of all mailcap files found from the current class loader (those of the application + those of javax.mail.api module).
But, if there are more than one application deployed, only the first to do so will have its mailcap loaded.
The design of javax.activation should be changed to take in account this side-effect of isolation: what happen if 2 applications define different classes for the same type/mime ??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month