JBoss WildFly: Starts but can't connect? - jboss

I just configured JBoss WildFly. It is running and it is accessible from the same machine, everything is working fine...
My problem is that it is not accessible from another system (I mean in a network, the server (hosted machine) URL can't access from another system).
How can I solve this?

By default jboss/wildfly binding to localhost, if you want change this, you can execute:
standalone.sh -b 0.0.0.0
listen on all IP addresses of the machine (if multihomed)
Another alternative is configure in standalone.xml the interfaces section.
Change:
<interfaces>
<interface name="management">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="public">
<inet-address value="127.0.0.1"/>
</interface>
</interfaces>
to:
<interfaces>
<interface name="management">
<!-- Use the IPv4 wildcard address -->
<any-ipv4-address/>
</interface>
<interface name="public">
<!-- Use the IPv4 wildcard address -->
<any-ipv4-address/>
</interface>
</interfaces>
Ref:
WildFly - Interfaces and ports
WildFly - Command line parameters
UPDATE
From Wildfly 8 <any-ipv4-address/> was deprecated and remove in Wildfly 9, then if you are in 9.x or higher use <any-address/>.
Deprecated. In the absence of -Djava.net.preferIPv4Stack=true, the
JVM cannot be instructed to bind a socket to all IPv4 addresses, but
only to IPv4 addresses, so the intended semantic cannot be obtained
via this setting alone. Since using any-addressType and setting
-Djava.net.preferIPv4Stack=true provides the same effect, this
any-ipv4-addressType will be removed in a future release.
Eg:
<interface name="global">
<!-- Use the wildcard address -->
<any-address/>
</interface>

The <any-ipv4-address/> is deprecated in WF 9, use:
...
<interface name="management">
<any-address/>
</interface>
...

(I summary 2 answers for a working solution)
I am using WildFly 10.0.0.Final - lastest version at writing time. Look for file standalone.xml like this:
On Windows
C:\tools\wildfly-10.0.0.Final\standalone\configuration\standalone.xml
Or Linux, like this:
/home/vyhn.net/wildfly-servlet-10.0.0.Final/standalone/configuration/standalone.xml
edit become to:
<interfaces>
<interface name="management">
<!-- Allow all external IP -->
<any-address/>
</interface>
<interface name="public">
<!-- Allow all external IP -->
<any-address/>
</interface>
</interfaces>
Then go to:
http://your_domain:9990/error/index.html
(port 9990 is default HTTP port, if you use firewall or iptables, remember open port 9990)
For example:
http://vyhn.net:9990/error/index.html
You will see it works successful.
Lastest reference (WildFly 10): https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports

Don't forget the firewall!
If you fixed the binding addresses and still can not connect to JBoss, try to work around the server's firewall.
To stop the firewall on Linux RHEL use this command:
/etc/init.d/iptables stop
An update (April 2018):
On RHEL7, where firewalld is used (rather than iptables), you may use:
systemctl stop firewalld
or open the specific Jboss/Wildfly ports (e.g. 8080/9990) with these two commands:
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload

You may use -b 0.0.0.0 to allow access regardless of the public ip assigned, e.g. for computers getting dynamic IP (using DHCP), I find this a convenient way.
Eclipse users: Beware that in Server configuration, the "Host name:" input is used to set the "-b" program argument, overriding your modifications!

Related

JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)

I want to run two deployed applications ( .ear ) in two instances of JBoss 6.0 at the same time
I have changed all used ports of both standalone.xml files including http , management-http , etc...
Like this:
application1.ear : socket-binding name="http" port="8080
application2.ear : socket-binding name="http" port="8081
application1.ear : name="management-http" port="9990
application2.ear : name="management-http" port="9991
Any Help is appreciated
Following are the two ways to run mutliple JBoss instance on same server.
Bind each instance to a different IP address
This is the easiest and most recommended way to solve this problem. If the server has multiple NICs then this is simple. If not, then one must "multi-home" the server. In other words, assign the server more than one IP address through OS configuration. Start the instances like so:
$JBOSS_HOME1/bin/run.sh -b <ip-addr-1>
$JBOSS_HOME2/bin/run.sh -b <ip-addr-2>
The same $JBOSS_HOME can be used with multiple "profiles" in $JBOSS_HOME/server. For example:
$JBOSS_HOME/bin/run.sh -b <ip-addr-1> -c node1
$JBOSS_HOME/bin/run.sh -b <ip-addr-2> -c node2
Service Binding Manager
Configure the "Service Binding Manager" to tell the JBoss instances which ports to use.
Uncomment the "jboss.system:service=ServiceBindingManager" MBean in $JBOSS_HOME/server/$PROFILE/conf/jboss-service.xml.
<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>
This tells JBoss to use the port numbering scheme defined by "ports-01" in $JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml. This scheme increases the second most significant digit of every port by 100. For example, the JNDI port is 1099 by default but 1199 using the ports-01 scheme; the HTTP port is 8080 by default but 8180 using the ports-01 scheme. The sample-bindings.xml file contains 4 port schemes:
ports-default
ports-01
ports-02
ports-03
You may want to configure the port set used at start up from the command line or through a system property. If so, adjust the MBean's ServerName to refer to a system property, for example:
<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">${jboss.service.binding.set:ports-default}</attribute>
<attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>
Now change it through the following property directly on run.sh/run.bat or add it to your run.conf options:
-Djboss.service.binding.set=ports-01
If you need more than 4 port sets defined in sample-bindings.xml by default, please refer to the following article for JBOSS 6 EAP:
https://access.redhat.com/site/solutions/237933

Wildfly 9 - How do I add jvm arguments to individual servers

I'm in the process of configuring a HA Wildfly cluster for session replication and I'm having trouble figuring out how to add JVM arguments to the individual servers in the domain. The arguments I add in domain.conf are applied to the process controller but not the individual servers. I can change the heap size for the server groups in domain.xml:
but I'm having trouble adding other arguments. Can I use this jvm section to add any argument? Is there another way to add arguments to server groups? Thanks.
You can use the jvm-options attribute on in CLI or you really want to edit the XML you can use <jvm-options/>.
CLI Example:
/server-group=main-server-group/jvm=default:write-attribute(name=jvm-options, value=["-XX:-HeapDumpOnOutOfMemoryError", "-XX:+UseCompressedOops"])
XML Example:
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="64m" max-size="512m"/>
<jvm-options>
<option value="-XX:-HeapDumpOnOutOfMemoryError"/>
<option value="-XX:+UseCompressedOops"/>
</jvm-options>
</jvm>
<socket-binding-group ref="full-sockets"/>
</server-group>
You can also define them at the server level if you need some setting only on a single server in the server group. See the host.xml for an example of that.

Wildfly 9 - mod_cluster on TCP

We are currently testing to move from Wildfly 8.2.0 to Wildfly 9.0.0.CR1 (or CR2 built from snapshot). The system is a cluster using mod_cluster and is running on VPS what in fact prevents it from using multicast.
On 8.2.0 we have been using the following configuration of the modcluster that works well:
<mod-cluster-config proxy-list="1.2.3.4:10001,1.2.3.5:10001" advertise="false" connector="ajp">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
</mod-cluster-config>
Unfortunately, on 9.0.0 proxy-list was deprecated and the start of the server will finish with an error. There is a terrible lack of documentation, however after a couple of tries I have discovered that proxy-list was replaced with proxies that are a list of outbound-socket-bindings. Hence, the configuration looks like the following:
<mod-cluster-config proxies="mc-prox1 mc-prox2" advertise="false" connector="ajp">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
</mod-cluster-config>
And the following should be added into the appropriate socket-binding-group (full-ha in my case):
<outbound-socket-binding name="mc-prox1">
<remote-destination host="1.2.3.4" port="10001"/>
</outbound-socket-binding>
<outbound-socket-binding name="mc-prox2">
<remote-destination host="1.2.3.5" port="10001"/>
</outbound-socket-binding>
So far so good. After this, the httpd cluster starts registering the nodes. However I am getting errors from load balancer. When I look into /mod_cluster-manager, I see a couple of Node REMOVED lines and there are also many many errors like:
ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to node1/1.2.3.4:10001, configuration will be reset: MEM: Can't read node
In the log of mod_cluster there are the equivalent warnings:
manager_handler STATUS error: MEM: Can't read node
As far as I understand, the problem is that although wildfly/modcluster is able to connect to httpd/mod_cluster, it does not work the other way. Unfortunately, even after an extensive effort I am stuck.
Could someone help with setting mod_cluster for Wildfly 9.0.0 without advertising? Thanks a lot.
I ran into the Node Removed issue to.
I managed to solve it by using the following as instance-id
<subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="${jboss.server.name}">
I hope this will help someone else to ;)
There is no need for any unnecessary effort or uneasiness about static proxy configuration. Each WildFly distribution comes with xsd sheets that describe xml subsystem configuration. For instance, with WildFly 9x, it's:
WILDFLY_DIRECTORY/docs/schema/jboss-as-mod-cluster_2_0.xsd
It says:
<xs:attribute name="proxies" use="optional">
<xs:annotation>
<xs:documentation>List of proxies for mod_cluster to register with defined by outbound-socket-binding in socket-binding-group.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:list itemType="xs:string"/>
</xs:simpleType>
</xs:attribute>
The following setup works out of box
Download wildfly-9.0.0.CR1.zip or build with ./build.sh from sources
Let's assume you have 2 boxes, Apache HTTP Server with mod_cluster acting as a load balancing proxy and your WildFly server acting as a worker. Make sure botch servers can access each other on both MCMP enabled VirtualHost's address and port (Apache HTTP Server side) and on WildFly AJP and HTTP connector side. The common mistake is to binf WildFLy to localhost; it then reports its addess as localhost to the Apache HTTP Server residing on a dofferent box, which makes it impossible for it to contact WildFly server back. The communication is bidirectional.
This is my configuration diff from the default wildfly-9.0.0.CR1.zip.
328c328
< <mod-cluster-config advertise-socket="modcluster" connector="ajp" advertise="false" proxies="my-proxy-one">
---
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
384c384
< <subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="worker-1">
---
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
435c435
< <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:102}">
---
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
452,454d451
< <outbound-socket-binding name="my-proxy-one">
< <remote-destination host="10.10.2.4" port="6666"/>
< </outbound-socket-binding>
456c453
< </server>
---
> </server>
Changes explanation
proxies="my-proxy-one", outbound socket binding name; could be more of them here.
instance-id="worker-1", the name of the worker, a.k.a. JVMRoute.
offset -- you could ignore, it's just for my test setup. Offset does not apply to outbound socket bindings.
<outbound-socket-binding name="my-proxy-one"> - IP and port of the VirtualHost in Apache HTTP Server containing EnableMCPMReceive directive.
Conclusion
Generally, these MEM read / node error messages are related to network problems, e.g. WildFly can contact Apache, but Apache cannot contact WildFly back. Last but not least, it could happen that the Apache HTTP Server's configuration uses PersistSlots directive and some substantial enviroment conf change took place, e.g. switch from mpm_prefork to mpm_worker. In this case, MEM Read error messages are not realted to WildFly, but to the cached slotmem files in HTTPD/cache/mod_custer that need to be deleted.
I'm certain it's network in your case though.
After a couple of weeks I got back to the problem and found the solution. The problem was - of course - in configuration and had nothing in common with the particular version of Wildfly. Mode specifically:
There were three nodes in the domain and three servers in each node. All nodes were launched with the following property:
-Djboss.node.name=nodeX
...where nodeX is the name of a particular node. However, it meant that all three servers in the node get the same name, which is exactly what confused the load balancer.
As soon as I have removed this property, everything started to work.

Weblogic Mvn Plugin Deploy Fails to Connect to server t3://localhost:7001

and thanks in advance for the help.
I am trying to get the oracle weblogic mvn plugin to run properly on my machine, but I am ultimately having difficulty with the connection to the admin server, and the plugins error message is not very useful in tracking the issue.
Overview:
I have essentially followed the following two pages to:
(a) install the plugin on my local repository:
http://docs.oracle.com/cd/E24329_01/web.1211/e24443/maven_deployer.htm#DEPGD383
(b) configure the maven plugin
http://www.oracle.com/technetwork/articles/soa/eisele-weblogic-netbeans-2193786.html
So my configuration looks as follows:
<profiles>
<profile>
<id>weblogicDeploy</id>
<properties>
<weblogic.server.version>12.1.2.0</weblogic.server.version>
<weblogic.server.adminurl>t3://127.0.0.1:7001</weblogic.server.adminurl>
<weblogic.server.middlewareHome>D:/appservers/weblogic</weblogic.server.middlewareHome>
<weblogic.server.serverName>AdminServer</weblogic.server.serverName>
<weblogic.server.userName>weblogic</weblogic.server.userName>
<weblogic.server.password>welcome1</weblogic.server.password>
</properties>
<dependencies>
<!--dependency>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-server-pom</artifactId>
<version>${weblogic.server.version}</version>
<type>pom</type>
<scope>provided</scope>
</dependency-->
</dependencies>
<build>
<plugins>
<!--
To have access to this plugin one must follow this guide:
http://docs.oracle.com/cd/E24329_01/web.1211/e24443/maven_deployer.htm#DEPGD383
The plugin is bundled with the web logic server - we cannot get it from the web unless we install it
into our nexus ...
(1) D:\weblogic\wlserver\server\lib>java -jar wljarbuilder.jar -profile weblogic-maven-plugin
(2) jar xvf c:\tmp\weblogic-maven-plugin.jar META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml
(3) mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml
-->
<plugin>
<!-- This is the configuration for the weblogic-maven-plugin -->
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>${weblogic.server.version}</version>
<configuration>
<middlewareHome>${weblogic.server.middlewareHome}</middlewareHome>
</configuration>
<executions>
<!-- Deploy the application to the WebLogic Server in the pre-integration-test phase -->
<execution>
<id>wls-deploy</id>
<!-- Summary Of phase:
process and deploy the package if necessary into an environment where integration tests can be run
-->
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<!--The admin URL where the app is deployed.
Here use the plugin's default value t3://localhost:7001-->
<adminurl>${weblogic.server.adminurl}</adminurl>
<user>${weblogic.server.userName}</user>
<password>${weblogic.server.password}</password>
<!--The location of the file or directory to be deployed-->
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<!--The target servers where the application is deployed. -->
<!--targets>${weblogic.server.serverName}</targets-->
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
There is nothing in the above configuration that appears to be wrong:
(a) The ( t3Url x userName x password) i can very easily validate that these are valid
$ netstat -an | grep "LISTEN" | grep "7001"
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING
TCP 127.0.0.1:7001 0.0.0.0:0 LISTENING
....
I can also use WLST to connect to the server:
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect('weblogic','welcome1','t3://127.0.0.1:7001')
Connecting to t3://127.0.0.1:7001 with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "whateverdomain".
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
(c) The previous point shows (a) the url, (b) the user name, (c) the password, (d) the target admin server... essentially everything.
But in mvn, running the mvn plugin, I ultimately always end up with the following exception.
Failed to execute goal com.oracle.weblogic:weblogic-maven-plugin:12.1.2.0:deploy (wls-deploy) on project whatevermy-war: weblogic.deploy.api.tools.deployer.DeployerException: Unable to connect to 't3://127.0.0.1:7001': weblogic.security.utils.KeyStoreConfiguration. Ensure the url represents a running admin server and that the credentials are correct. If using http protocol, tunneling must be enabled on the admin server. -> [Help 1]
The exception message above is a very clumnsy one:
(a) the plugin knows the url it was given, it knows it was not told to use http it is the t3 protocl
(b) if a play with the url port and setup an invalid port, i do get a socket exception and the exception message from the plugin is exactly the same thing...
there ought to be a configuraiton aspect that i have wrong, admin server name, hidden security policies ... something, but I am at this point not seing what it may be.
By th way, I have commented the dependency on the server pom, since this onther of those dependencies that you cannot fetch from a remote repository and I do not know which jar in the web logic server is hiding the pom. Otherwise, i would have installed also in my local repository. I doubt this is relevant though, since the plugin seems to be satisfied with trying to connect to weblogic.
Many thanks.
Fixed the issue by following a different oracle guide on how to install the maven plugin.
This guide seems to do a better job at installing the web logic plugin.
http://docs.oracle.com/middleware/1213/wls/WLPRG/maven.htm
Quoting the relevant part of the oracle installation guide.
Install the Oracle Maven sync plug-in and run the push goal:
Change directory to ORACLE_HOME\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.1.3.
mvn install:install-file -DpomFile=oracle-maven-sync-12.1.3.pom -Dfile=oracle-maven-sync-12.1.3.jar.
mvn com.oracle.maven:oracle-maven-sync:push -Doracle-maven-sync.oracleHome=c:\oracle\middleware\oracle_home\.
Adapt the guide to your own installtion path of the product, and wait for the maven push command to build successfully. Hopefully the weblogic plugin you will get out of this experiecen will turn out to be better than the one installed by the first guide.
After this, the only thing i needed to change in my configuration was the plugin version.
<weblogic.server.version>12.1.2-0-0</weblogic.server.version>
And voila, this time I got a working plugin instead of a make-believe toy.
u can find 'KeyStoreConfiguration' in com.oracle.weblogic.security.encryption_1.0.0.0.jar which in folder /weblogic/weblogic12/wlserver/modules.
just put KeyStoreConfiguration.class input weblogic-maven-plugin, all goes well!
This is the same answer given by #crimsonwisp. Thanks to #DanielHernández for his comments. Here are the steps I followed to get rid of
Failed to execute goal com.oracle.weblogic:weblogic-maven-plugin:12.1.2.0:deploy (wls-deploy) on project whatevermy-war: weblogic.deploy.api.tools.deployer.DeployerException: Unable to connect to 't3://127.0.0.1:7001': weblogic.security.utils.KeyStoreConfiguration. Ensure the url represents a running admin server and that the credentials are correct. If using http protocol, tunneling must be enabled on the admin server. -> [Help 1]
From your wlserver, find the weblogic.security.encryption jar
$ find . -name com.oracle.weblogic.security.encryption*
./modules/com.oracle.weblogic.security.encryption_2.0.0.0.jar
Copy the contents of this jar into weblogic-maven-plugin.jar. Assuming you are in INSTALL_HOME/wlserver/server/lib directory.
$ mkdir -p /tmp/wlsmaven
$ cp ../../modules/com.oracle.weblogic.security.encryption_2.0.0.0.jar /tmp/wlsmaven/
$ cp weblogic-maven-plugin.jar /tmp/wlsmaven/
$ cd /tmp/wlsmaven
$ jar xvf com.oracle.weblogic.security.encryption_2.0.0.0.jar
# Update jar with classes from weblogic.security.encryption jar
$ jar uvf weblogic-maven-plugin.jar weblogic
$ cd -
$ cp /tmp/wlsmaven/weblogic-maven-plugin.jar .
Run to install the maven command again to install in your local repo or whereever you want this to be.
$ mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml

CruiseControl.NET no connection can be made?

I am setting up CruiseControl.NET and I get the following error message on the webdashboard:
No connection could be made because the target machine actively refused it 127.0.0.1:21234
The Url it is looking for is: tcp://localhost:21234/CruiseManager.rem
However the ccnet website in IIS has its tcp port set to 82.
So I use the following Url to navigate to the webdashboard http://127.0.0.1:82/ccnet/ViewFarmReport.aspx
I tried changing the Tcp port in IIS to 21234 and I get the following error message on the webdashboard:
Tcp channel protocol violation: expecting preamble.
I have also tried opening the port with the following command:
netsh firewall add portopening TCP 21234 CCNET
When I try and start the CCNET service I get the following message
The CruiseControl.NET Server service started then stopped. Some services stop automatically if they have no work to do....
Can anyone help me with this problem please?
EDIT - Adding config file
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:define PublishDir="C:\Deploy\Portal2.0Build"/>
<project name="Portal2.0">
<workingDirectory>C:\PortalCruiseControl\Working</workingDirectory>
<artifactDirectory>C:\PortalCruiseControl\Artifacts</artifactDirectory>
<webURL>http://192.168.17.59:82/ccnet</webURL>
<triggers>
<intervalTrigger name="continuous" seconds="10"
buildCondition="IfModificationExists"/>
</triggers>
<sourcecontrol type="svn">
<trunkUrl>https://portal2003.local:8443/svn/portalv2.0/trunk</trunkUrl>
<executable>C:\Program Files (x86)\VisualSVN Server\bin\svn.exe</executable>
<username>ccnet</username>
<password>***</password>
<cleanCopy>true</cleanCopy>
</sourcecontrol>
<tasks>
<msbuild>
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
<projectFile>Portal2.0.sln</projectFile>
<buildArgs>
/target:build;publish /p:Configuration=Release /p:MSBuildExtensionsPath=C:\Progra~2\MSBuild /p:MSBuildEmitSolution=1 /p:publishdir=C:\Deploy\Portal2.0Build /verbosity:diag
</buildArgs>
<logger>
C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll
</logger>
</msbuild>
</tasks>
<labeller type="assemblyVersionLabeller">
<major>2</major>
<minor>0</minor>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
<publishers>
<statistics />
<xmllogger />
<package>
<name>ZipFilePublish</name>
<compression>9</compression>
<always>false</always>
<flatten>false</flatten>
<baseDirectory>$(PublishDir)</baseDirectory>
<dynamicValues>
<replacementValue property="name">
<format>C:\Deploy\Builds\PortalBuild{0}.zip</format>
<parameters>
<namedValue name="$CCNetLabel" value="Default" />
</parameters>
</replacementValue>
</dynamicValues>
<files>
<file>*.*</file>
<file>**\*</file>
</files>
</package>
<email from="bla" mailhost="bla" port="25" userName="bla"
password="bla" includeDetails="TRUE" useSSL="FALSE">
<users>
<user name="User1" group="Portal" address=""/>
</users>
<groups>
<group name="Portal">
<notifications>
<notificationType>change</notificationType>
</notifications>
</group>
</groups>
</email>
</publishers>
</project>
The first error message is probably caused by CCNET service not running because of which the web dashboard can't connect to it. It should go away as soon as you fix the ccnet.config so that service starts running.
The second problem ("Ilegal characters in path"; you seem to have already figured out the missing nodes part) is caused by msbuild/executable element. It seems that CC.NET doesn't like whitespace and especially new line characters inside it's value. Replacing:
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
with:
<executable>C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe</executable>
should fix the problem.
Another hint: when you're having problems with the validity of your ccnet.config file, try using CCValidator.exe (it's in your CruiseControl.NET\server folder). It usually points out the problematic part of the config file quite nicely (although that wasn't the case with "Illegal characters in path" problem - I had to comment out specific parts of the config to find the offending node).
The first message you receive (connection actively refused) makes me think of a firewall which is blocking the port you're using.
The second problem could be anything. It could for instance be an error in your XML configuration (ccnet.config) file. Can you find any pointers in the Windows Eventlog ?
Regarding the 2nd problem: did you try to run the CC.NET server from the command line?
If you've got an error in your XML configuration, this will give you a more meaningful error message.
Which account are you using to run the Windows service?
Have you checked your ccnet's dashboard.config file?
It has the following line in it:
<server name="local" url="tcp://localhost:21234/CruiseManager.rem" ... />
Try changing the port on that to 82 and then restarting the website (you should be just able to add a space to the web.config file and save and IIS will restart the website).
Sounds like you're confusing two different functions:
tcp://localhost:21234
This is the default remoting port for clients like CCTray. This is not used for the IIS web site (dashboard).
Configuration document is likely missing Xml nodes required for properly populating CruiseControl co nfiguration. Missing Xml node (packageList) for required member (ThoughtWorks.CruiseControl.Core.Publishers.Package Publisher.PackageList)
Your example config is missing required packageList node.
A misleading error message. The port really is 21234, not 82. I got the same errors. The fix was to start ccnet.exe from the desktop shortcut to discover that the real problem was illegal code in my ccnet.config file.
After fixing the ccnet.config file, the problem moved on. When attempting to build, the system would not let the subversion client modify the read-only marker files in the checked out repo.
In my case I misprinted project configuration file name in ccnet.config instead of timescheduler.config it were timesheduler. When I fixed file name I was able to run ccnet service.
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:include href="definitions.xml" xmlns:cb="urn:ccnet.config.builder"/>
<cb:include href="projects/timescheduler.config" xmlns:cb="urn:ccnet.config.builder"/>
</cruisecontrol>