[JBoss JIRA] (AS7-3786) Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-3786?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on AS7-3786:
---------------------------------
Those tests are there to test the protocol and the subsystems. Their intent is not to test ipv6 etc. That gets tested in the real testsuite
> Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
> ------------------------------------------------------------------
>
> Key: AS7-3786
> URL: https://issues.jboss.org/browse/AS7-3786
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
> Fix For: 7.1.1.Final
>
>
> Some TestCases are hard bound to *127.0.0.1* IP address. I think, it is useless - especially testing in IPv6 environment is impossible in this case for a such TestCase(-s).
> These classes aren't in integration testsuite part, it is in other places.
> Some of them are (maybe I've overlooked some others):
> - org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
> - org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase
> - org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase
> - org.jboss.as.controller.ModelControllerClientTestCase
> - org.jboss.as.jmx.JMXSubsystemTestCase
> - org.jboss.as.jmx.ModelControllerMBeanTestCase
> Otherwise these tests are run *before* IP address transformation (usually used node0 variable and tranforms AS7 config file standalone-*.xml), so maybe there isn't present now any mechanism how to get/propagate proper (and wanted) IP address.
> Also note - some of them are hardcoded to IP name alias *localhost* - see JBPAPP-8132 for localhost vs. localhost6.
--
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] (JBAS-9472) Improve the processing time of a request with a large number of parameters.
by Toshio Oya (JIRA)
Toshio Oya created JBAS-9472:
--------------------------------
Summary: Improve the processing time of a request with a large number of parameters.
Key: JBAS-9472
URL: https://issues.jboss.org/browse/JBAS-9472
Project: Application Server 3 4 5 and 6
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.1.0.GA
Environment: Linux, Windows
Reporter: Toshio Oya
Assignee: Remy Maucherat
We ported an existing business application from Tomcat 5.5.x to JBoss AS 5.1.0.GA.
When running the application on JBoss AS, we found that the processing of a POST request with a large number of parameters takes longer than doing it on Tomcat.
We investigated the cause, it occurred in the processing of org.apache.tomcat.util.http.Parameters class in JBossAS/JBossWeb.
So, we've created a patch for JBoss AS to improve it.
We applied this patch to JBoss AS, then the processing time of 10,000 parameters in a POST request is now as follows.
- Time of processing request.getParameterMap().
Before:
22,635.0 msec (average of 3 times)
After:
2.3 msec (average of 3 times)
We want to incorporate this patch in JBoss AS.
Using our sample application:
1. Build
$ cd /tmp
$ unzip sample-app.zip
$ cd sample-app
$ mvn package
2. Deploy
Please copy the test_war-1.0.war to your deploy directory for your JBossAS.
$ cd blank_war/target/
$ cp test_war-1.0.war $JBOSS_HOME/server/<profile>/deploy
3. Test
Access the url - http://server:port/test_war-1.0/ via a web browser.
Press the "click" button in the page.
And, press "OK" button on a dialog.
The time of processing request.getParameters() is logged to CONSOLE and log/server.log.
ex)
13:42:43,084 FATAL [SampleTestAction] request.getParameterMap() taken 20467 msec.
About patch.
modified-5.1.0.GA.zip
- B2CConverter.java ... replacement of org.apache.tomcat.util.buf.B2BConverter
- Parameters.java ... replacement of org.apache.tomcat.util.http.Parameters
- LocalStrings.properties
... added a new property file to org.apache.tomcat.util.http.
Best regards,
Team.
--
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-4046) Subsystem parser checking test fails
by Stefano Maestri (JIRA)
Stefano Maestri created AS7-4046:
------------------------------------
Summary: Subsystem parser checking test fails
Key: AS7-4046
URL: https://issues.jboss.org/browse/AS7-4046
Project: Application Server 7
Issue Type: Bug
Components: JCA
Reporter: Stefano Maestri
Assignee: Stefano Maestri
Fix For: 7.1.2.Final
Subsystem parser checking test fails.
To reproduce, run ignored test in org.jboss.as.connector.subsystems.jca.ComplexResourceAdaptersSubsystemTestCase
Results :
Tests in error:
testResourceAdapterWith2ConDefAnd2AdmObj(org.jboss.as.connector.subsystems.jca.ComplexResourceAdaptersSubsystemTestCase): JBAS014822: Required parameter wrap-xa-resource is not present. {"operation" => "add","class-name" => "org.jboss.as.test.smoke.deployment.rar.MultipleManagedConnectionFactory1","jndi-name" => "java:jboss/name2","address" => [("subsystem" => "resource-adapters"),("resource-adapter" => "multiple.rar"),("connection-definitions" => "Pool2")]}
--
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-3786) Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-3786?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek updated AS7-3786:
--------------------------------
Assignee: Ondrej Zizka (was: Pavel Janousek)
> Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
> ------------------------------------------------------------------
>
> Key: AS7-3786
> URL: https://issues.jboss.org/browse/AS7-3786
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Critical
> Fix For: 7.1.1.Final
>
>
> Some TestCases are hard bound to *127.0.0.1* IP address. I think, it is useless - especially testing in IPv6 environment is impossible in this case for a such TestCase(-s).
> These classes aren't in integration testsuite part, it is in other places.
> Some of them are (maybe I've overlooked some others):
> - org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
> - org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase
> - org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase
> - org.jboss.as.controller.ModelControllerClientTestCase
> - org.jboss.as.jmx.JMXSubsystemTestCase
> - org.jboss.as.jmx.ModelControllerMBeanTestCase
> Otherwise these tests are run *before* IP address transformation (usually used node0 variable and tranforms AS7 config file standalone-*.xml), so maybe there isn't present now any mechanism how to get/propagate proper (and wanted) IP address.
> Also note - some of them are hardcoded to IP name alias *localhost* - see JBPAPP-8132 for localhost vs. localhost6.
--
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-3786) Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/AS7-3786?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek commented on AS7-3786:
-------------------------------------
Ondrej,
yes there are still there...:-(
As you could see [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-experiments/3/c...], recent master contains for ex. org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase, org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase or org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase still bound directly to 127.0.0.1 although the run is invoked as:{code}./build.sh clean install -Dmaven.test.failure.ignore -Dskip-download-sources -U -B -fae -DallTests -Dnode0=10.16.95.7 -Dnode1=10.16.95.8 -DudpGroup=227.43.89.216{code}
Mentioned Jenkins job (AS7-TS-linux-experiments) is used by mine as reference for comparing what is related to IPv6 only and what is general issue with some bad approach and not using specified (wanted) IP address(-es).
> Some non-Arquillian TestCases are run against hard-coded 127.0.0.1
> ------------------------------------------------------------------
>
> Key: AS7-3786
> URL: https://issues.jboss.org/browse/AS7-3786
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.Final
> Reporter: Pavel Janousek
> Assignee: Pavel Janousek
> Priority: Critical
> Fix For: 7.1.1.Final
>
>
> Some TestCases are hard bound to *127.0.0.1* IP address. I think, it is useless - especially testing in IPv6 environment is impossible in this case for a such TestCase(-s).
> These classes aren't in integration testsuite part, it is in other places.
> Some of them are (maybe I've overlooked some others):
> - org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
> - org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase
> - org.jboss.as.controller.test.RemoteProxyControllerProtocolTestCase
> - org.jboss.as.controller.ModelControllerClientTestCase
> - org.jboss.as.jmx.JMXSubsystemTestCase
> - org.jboss.as.jmx.ModelControllerMBeanTestCase
> Otherwise these tests are run *before* IP address transformation (usually used node0 variable and tranforms AS7 config file standalone-*.xml), so maybe there isn't present now any mechanism how to get/propagate proper (and wanted) IP address.
> Also note - some of them are hardcoded to IP name alias *localhost* - see JBPAPP-8132 for localhost vs. localhost6.
--
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-4031) file.encoding is not correct
by Idar Borlaug (JIRA)
Idar Borlaug created AS7-4031:
---------------------------------
Summary: file.encoding is not correct
Key: AS7-4031
URL: https://issues.jboss.org/browse/AS7-4031
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.0.Final, 7.0.2.Final
Environment: OpenSuse 12, SLES 11
Reporter: Idar Borlaug
When starting jboss i get file.encoding = ANSI_X3.4-1968 in boot.log
My jbossuser has locale:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
java -jar test.jar print file.encoding=UTF-8
Java reads the locale info fine, jboss just ignores it.
Setting file.encoding=UTF-8 has no effect in jboss 7.0.2 (the boot.log prints UTF-8, but new File("filename") still uses something else) but works in 7.1.0
--
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-4034) Allow the set of default system modules to be amended
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-4034:
-----------------------------------
Summary: Allow the set of default system modules to be amended
Key: AS7-4034
URL: https://issues.jboss.org/browse/AS7-4034
Project: Application Server 7
Issue Type: Task
Components: OSGi
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 7.1.1.Final
If a bundle has a dependency on log4j. We need to setup visibility to that module like this
{code}
<property name="org.jboss.osgi.system.modules">
javax.api,
javax.inject.api,
org.apache.log4j,
org.apache.xerces,
org.jboss.as.configadmin,
org.jboss.as.osgi,
org.jboss.logging,
org.jboss.modules,
org.jboss.msc,
org.jboss.osgi.framework,
org.jboss.osgi.repository,
org.slf4j,
</property>
{code}
{code}
<property name="org.osgi.framework.system.packages.extra">
org.apache.log4j;version=1.2
</property>
{code}
All other modules except org.apache.log4j are configured by default.
Currently there is no way to amend the set of default modules.
--
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-3631) Using DMR for generic config application
by Michael Voegele (JIRA)
Michael Voegele created AS7-3631:
------------------------------------
Summary: Using DMR for generic config application
Key: AS7-3631
URL: https://issues.jboss.org/browse/AS7-3631
Project: Application Server 7
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Michael Voegele
Assignee: Alexey Loubyansky
We are looking for a generic way on how to apply configuration to a domain. We want to use a way over an xml template, convert the xml template to json and setting the attributes on a ModelNode. This way, we don't need to wrap all possible attributes in java code.
Example:
See attached file 'template-data-source.xml'. This file is a possible template for a normal datasource. The intention is that developers fill in that template and over a mechanism, it is applied to their profile. The mechanism converts the xml template to json, which is then applied on a ModelNode:
{code}
private void setXmlAttributes(ModelNode operationNode) {
// convert xml to json
JSONObject jsonObject;
try {
jsonObject = XML.toJSONObject(dmrConfigArtifact.getXmlTemplate());
} catch (JSONException e) {
throw new IllegalArgumentException(e);
}
// set json attributes on operation
ModelNode attributes = ModelNode.fromJSONString(jsonObject.toString());
List<Property> properties = attributes.asPropertyList();
for (Property property : properties) {
operationNode.get(property.getName()).set(property.getValue());
}
}
{code}
This node is then added to the configuration using normal 'add' operation (of course address and operation are also set on the operationNode, then executed by 'ModelControllerClient').
This mechanism works fine for a normal datasource. However, if I try an xa-datasource, it does not work, as it contains subnodes (xa-datasource-properties), see attached file 'template-xa-data-source.xml'.
When reading a node using 'read-resource', there is the possibility to set 'recursive=true' on the operation. This way, all subnodes are also returned. Is there a way to apply a node in a recursive way?
I would like to have a statement, if it is a bug, that when adding a node containing subnodes, the subnodes cannot be handled by DMR automatically. Is it correct, that every subnode has to be handled/added separately?
Thanks in advance for your answers.
--
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