Menu
▾
▴
jboss-dev-forums
|
From: <rya...@jb...> - 2005-06-14 22:05:00
|
The clustering tests run against node0 and node1, so the natural thing to do is to get the rest of the testsuite to run against ${node0}
As for #1, 4 things are required:
a. The start-jboss* macros should to default to ${node0} instead of localhost.
b. JUnit tests should use JBossTestCase/JBossTestServices API to find URLs instead of hard coding them, just like the clustering tests do now.
c. Serverside test deployments should use jboss.bind.addr
d. src/resources/** should be filtered with a token like @NODE_0@.
3. This will only allow you to run targets like one-test or tests-standard-unit which don't start jboss servers. The entire "tests" target could not be run against a remote box?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881489#3881489
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881489
|
|
From: <cle...@jb...> - 2005-06-14 22:15:50
|
For 2) What about defining a property like jboss.tomcat.udp.bind and jboss.ejb.udp.bind, in the same way we do to jboss.bind.address? Or we could at least do some replace into /build/output/server/relevant-places. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881490#3881490 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881490 |
|
From: <sco...@jb...> - 2005-06-14 23:40:30
|
There should be no need to service specific bind address properties. Every service should already be defaulting its bind address to the jboss.bind.address property. Where do you see a need for a service specific bind address? Also, every server start macro does bind the server to a specific address using the -b option as far as I know. The problem is that localhost is used for the tests target. The client side of the tests is what is needed most as there are many hard coded localhost references. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881495#3881495 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881495 |
|
From: <cle...@jb...> - 2005-06-14 23:57:44
|
This is to the UDP IPs. It's very common having conflicts between different runnings when both are running the testsuite in the same environment/network. (for example dev01, 2 and 3). I didn't mean specifically to change our distribution, but to have some way to isolate different clustered UDPs as Adrian has mentioned: anonymous wrote : 2) Issues with some services using udp (e.g. clustering) that will still pickup requests | that are intended for a specific machine running the testsuite. This is for the same | problem as (1), but also on the same network where you want to control the | machines in the cluster. | I don't know really how to resolve this one. Since you are basically with broadcast | ports that need to be isolated across different users on the same network. | Some sort of mechanism like DHCP where you can lease udp socket/ports? :-) | So, that's why I suggested the creation of the property. We would do a in those cluster UDP configs if the property is available. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881496#3881496 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881496 |
|
From: <ad...@jb...> - 2005-06-15 00:02:21
|
The problem is caused not because the multicast aren't bound to the jboss.bind.address (they are). This allows multiple servers to boot on the same machine. The problem is that they actually communicate over the udp groups, so the ip binding does not matter. Any servers on the same machine or network are going to form a cluster which is not what you want when you have two or more people trying to run isolated tests. To properly isolate the indepenent tests, you need a simple notion to isolate the udp groups. e.g. Each user gets their own mcast address and then they can use ports within that address. As Clebert said, a simple jboss.mcast.address should solve the problem? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881498#3881498 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881498 |
|
From: <ad...@jb...> - 2005-06-15 00:04:39
|
"sco...@jb..." wrote : | Also, every server start macro does bind the server to a specific address using the -b option as far as I know. The problem is that localhost is used for the tests target. | Only because I fixed this yesterday. I didn't even check them all, just the unit tests. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881499#3881499 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881499 |
|
From: <ad...@jb...> - 2005-06-15 00:14:52
|
"ad...@jb..." wrote : | The problem is that they actually communicate over the udp groups, | so the ip binding does not matter. | Of course I assume that the bind addresses are reachable from one another which is the case at least in our lab. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881500#3881500 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881500 |
|
From: <sco...@jb...> - 2005-06-15 01:40:20
|
So the standard cluster-service.xml config should come with the multicast group parameterized as well then:
| <mbean code="org.jboss.ha.framework.server.ClusterPartition"
| name="jboss:service=${jboss.partition.name:DefaultPartition}">
|
| <!-- Name of the partition being built -->
| <attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
| ...
| <Config>
| <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" mcast_port="45566"
|
|
This is a sufficiently general configuration issue.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881508#3881508
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881508
|
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:14:54
|
IP address parameterization in testsuite http://jira.jboss.com/jira/browse/JBAS-1864 The IP address parameterization in the JBoss testsuite is a modification which will allow the testsuite to run off any IP instead of binding exclusively to localhost. Without these modifications the testsuite runs its tests only on localhost and will only allow one person on a particular machine to run the testsuite (running multiple testsuites will cause conflicts). With these modifications in place, multiple testsuites can be run on the same machine. Here is the core modification: I applied a Filterset on the NODE_0 token for the src/resources directory, replacing the token with the ${node0} property. The files containing the token are .xml and .properties files. The chunk of code is as follows: | <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}"> | <fileset dir="${source.resources}"> | <include name="**/*.xml"/> | <include name="**/*.properties"/> | </fileset> | <filterset> | <filter token="NODE_0" value="${node0}"/> | </filterset> | </copy> | <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}"> | <fileset dir="${source.resources}"> | <exclude name="**/*.xml"/> | <exclude name="**/*.properties"/> | </fileset> | </copy> | The ${node0} property can be instantiated as follows: Example : $ build -Dnode0=192.168.xxx.xxx tests For now it is not advised to run with node0 having a value other than localhost because localhost is still hardcoded in several portions of the testsuite .java files. That is still Work in Progress. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882294#3882294 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882294 |
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:17:34
|
the following are files which were changed in /testsuite/ to accomodate for node0 : build.xml imports/test-jars.xml imports/code-generation.xml imports/server-config.xml src/resources/cosnaming.jndi.properties src/resources/iiop.jndi.properties src/resources/jndi.properties src/resources/log4j.xml src/resources/aop/META-INF/jboss-service.xml src/resources/aop/invocationlog/META-INF/jboss-service.xml src/resources/cluster/http/cluster-bindings.xml src/resources/isolation/a/ejb/META-INF/jboss.xml src/resources/jca/autocommit/hsqldb-singleconnection-ds.xml src/resources/jca/ha/test-ha-ds.xml src/resources/jca/inflow/META-INF/ra.xml src/resources/jca/inflowmdb/META-INF/ejb-jar.xml src/resources/jca/jdbc/testdriver-ds.xml src/resources/jca/jdbc/META-INF/jboss-service.xml src/resources/naming/jar/META-INF/jboss.xml src/resources/security-srp/service-inf/jboss-service.xml src/resources/test-configs/webservice-ssl/deploy/jbossweb-tomcat55.sar/server.xml src/resources/testbeancluster/cif-ds.xml src/resources/web/SecuredDD.xml src/resources/web/UnsecuredDD.xml src/resources/webservice/admindevel/META-INF/jboss-client.xml src/resources/webservice/attachment/META-INF/jboss-client.xml src/resources/webservice/encstyle/document/jboss-client.xml src/resources/webservice/encstyle/rpc/jboss-client.xml src/resources/webservice/exception/META-INF/jboss-client.xml src/resources/webservice/header/META-INF/jboss-client.xml src/resources/webservice/jbws124/META-INF/jboss-client.xml src/resources/webservice/jbws153/META-INF/jboss-client.xml src/resources/webservice/jbws163/META-INF/jboss-client.xml src/resources/webservice/jbws165/META-INF/jboss-client.xml src/resources/webservice/jbws168/META-INF/jboss-client.xml src/resources/webservice/jbws217/META-INF/jboss-client.xml src/resources/webservice/jbws68/META-INF/jboss-client.xml src/resources/webservice/jbws70/META-INF/jboss-client.xml src/resources/webservice/jbws71/META-INF/jboss-client.xml src/resources/webservice/jbws79/META-INF/jboss-client.xml src/resources/webservice/jbws82/META-INF/jboss-client.xml src/resources/webservice/jbws83/META-INF/jboss-client.xml src/resources/webservice/jbws84/META-INF/jboss-client.xml src/resources/webservice/marshalltest-doclit/META-INF/jboss-client.xml src/resources/webservice/marshalltest-rpcenc/META-INF/jboss-client.xml src/resources/webservice/marshalltest-rpclit/META-INF/jboss-client.xml src/resources/webservice/message/META-INF/jboss-client.xml src/resources/webservice/samples/client-appl/config.xml src/resources/webservice/samples/client-appl/META-INF/jboss-client.xml src/resources/webservice/samples/client-ejb/META-INF/jboss.xml src/resources/webservice/samples/client-web/WEB-INF/jboss-web.xml src/resources/webservice/samples2/doclit/config-client.xml src/resources/webservice/samples2/doclit/jboss-client.xml src/resources/webservice/samples2/rpclit/jboss-client.xml View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882295#3882295 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882295 |
|
From: <ad...@jb...> - 2005-06-21 22:25:45
|
The jboss-client.xml are parsed using the MetaData classes.
These already perform the system property replacement so you should use
| ${jbosstest.server.host:localhost}
|
In the code, it should be using JBossTestCase.getServerHost()
although I don't believe there is an equivalent for serverside processing.
I can't comment on the others without looking at them.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882296#3882296
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882296
|
|
From: hbarlas <nu...@jb...> - 2005-06-21 22:35:21
|
Some of the hardcoded instances of localhost in the testsuite can be replaced by reusing a few methods in JbossTestClusteredServices.java
Should these methods (example : getNamingURL(), getHttpURL() ) be pulled up into JBossTestServices.java?
Consider for example the use of getHttpURL() in org.jboss.test.webservice.samples.ServerSideJSETestCase:
URL url = new URL("http://localhost:8080/ws4ee-samples-server-jse/Organization?wsdl");
Here I could say something like :
URL url = new URL(getHttpURL(0) + "/ws4ee-samples-server-jse/Organization?wsdl");
where getHttpURL(0) will give me a url consisting of node0 instead of localhost.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882297#3882297
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882297
|
|
From: hbarlas <nu...@jb...> - 2005-06-23 21:20:48
|
"ad...@jb..." wrote : The jboss-client.xml are parsed using the MetaData classes.
|
| These already perform the system property replacement so you should use
|
| | ${jbosstest.server.host:localhost}
| |
|
Adrian, I couldn't get this property to evaluate to the host ie 'node0'. It evaluates to the default value "localhost" each time probably because the property is not set in the first place. I confirmed from the one-test target and 'jbosstest.server.host' is indeed specified there as a system property. Am I doing something wrong?
here is how I am testing:
| $ build -Dnode0=hbarlas -Dtest=??? one-test
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882558#3882558
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882558
|
|
From: hbarlas <nu...@jb...> - 2005-06-24 23:14:09
|
ok got it to work but I had to use the following property:
| ${jboss.bind.address}
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882677#3882677
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882677
|
|
From: hbarlas <nu...@jb...> - 2005-06-30 18:50:38
|
This post is regarding the IP Address parameterization in the JBoss testsuite. I will go over the idea again of what is being accomplished. Basically by allowing parameterization of the testsuite it will be possible to run the testsuite on an IP other than the current hardcoded 'localhost'. Below is a summary of what changes were made to the testsuite, their impact and comparisons between the unmodified testsuite and the 'parameterized' testsuite.
======================
DESCRIPTION OF CHANGES
======================
----------
Filtersets
----------
1) Filtersets were applied in the "compile-resources" target to parameterize all .xml, .properties and .wsdl files.
2) In imports/code-generation.xml the "init-code-generation" target now depends on the "compile-resources" target.
This is needed because the token substitution is performed in the "compile-resources" target. It must be called
before code-generation starts to allow the proper IP to be propagated in build/resources.
3) In imports/test-jars.xml all occurences of {source.resources} have been replaced by {build.resources}.
The "compile-resources" target ensures that the @NODE_0@ token in src/resources is substituted correctly with the IP to form build/resources. Therefore test-jars.xml must reference {build.resources} instead of {source.resources}
---------------------
Property Substitution
---------------------
1) In all the jboss-client.xml files, localhost is replaced with the property {jboss.bind.address}.
2) Occurrences of localhost in the source code in src/main have been parameterized as follows:
- all the testcase source files use getServerHost()
- static variables and methods use System.getProperty("jbosstest.server.host" , "localhost")
- server related code uses System.getProperty("jboss.bind.address" , "localhost")
============
IMPACT
============
There won't be any difference in using the testsuite, it will output the same results as the current one.
When used with a specified IP on non-clustered tests, it will run exclusively on that IP. Since these are big changes to the testsuite, my suggestion is to tag the existing testsuite as 'pre-parameterized'.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883267#3883267
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883267
|
|
From: <ad...@jb...> - 2005-07-07 01:20:07
|
We need to revert JBAS-1864. This is a step backwards. The keyword is *incremental* builds. Parameterization should be at runtime. I don't want to have to rebuild the testsuite to change the host I want to run tests against. I also eventually want a modular/declarative/incremental testsuite build that I can run from inside JBoss/IDE on an embedded JBoss server. What is the issue with the system properties? They should be accepted in all deployments. If the problem is that the server uses a different a system property (jboss.bind.address) to the testsuite (jboss.test.serverhost, nodeN.xxx.yyy) then we need to address this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883940#3883940 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883940 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X