-
1. Re: Web context not registered in domain mode
jaikiran Aug 14, 2014 12:54 AM (in response to dejanm)How are you starting the domain and how are you deploying the application?
-
2. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 3:28 AM (in response to jaikiran)Using bin/domain and bin/jboss-cli tools. So:
./domain.sh --host-config=host-master.xml -Djboss.bin.address.management=localhost
And then:
./jboss-cli.sh --connect controller=remoting://localhost
deploy /home/dejan/dev/siebog/trunk/siebog/siebog.war --name=siebog --server-groups=xjaf2x-group
server.log, host-master.xml, and domain.xml are available here: http://perun.pmf.uns.ac.rs/mitrovic/files.zip
-
3. Re: Web context not registered in domain mode
jaysensharma Aug 14, 2014 4:00 AM (in response to dejanm)From your server.log we see that the Application was deploying fine and the persistence as well as the EJBs were deploying fine, However as soon as the following WARN message appeared in your logs the services started getting stopped.
2014-08-14 09:19:16,448 WARN [org.jboss.weld.Validator] (MSC service thread 1-1) WELD-001471: Interceptor method postConstruct defined on class siebog.server.xjaf.managers.ConnectionManager is not defined according to the specification. It should not throw javax.naming.NamingException, which is a checked exception. . . 2014-08-14 09:19:53,350 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 84) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory . . 2014-08-14 09:19:53,372 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 79) MODCLUSTER000002: Initiating mod_cluster shutdown 2014-08-14 09:19:53,372 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 84) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'siebog#Radigost' . . 2014-08-14 09:19:53,967 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.1.0.Beta5 stopping
Start - Time : 2014-08-14 09:17:58,154
Stop - Time : 2014-08-14 09:19:53,967
So it looks like the code "siebog.server.xjaf.managers.ConnectionManager" might be causing the issue. Can you check if it is throwing any javax.naming.NamingException or not ?
What kind of application is it "siebog" ? Is it any kind of resource manager? What kind of connection dos it manage?
-
4. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 4:44 AM (in response to jaysensharma)Thank you, I've just checked it, but no, it does not throw any exceptions.
The application is actually a multi-agent middleware. It maps agents to EJBs and optionally exposes them as RESTful services. The static HTML pages are just an admin console. You may get the actual server I'm using, along with the .war file here: http://perun.pmf.uns.ac.rs/xjaf/download.html The source code is available at svn://perun.pmf.uns.ac.rs/siebog/trunk
-
5. Re: Web context not registered in domain mode
jaysensharma Aug 14, 2014 5:45 AM (in response to dejanm)The link contains around 141.9 MB content.
In which i was not able to find the "siebog.server.xjaf.managers.ConnectionManager". (however i do not think that the previously mentioned WARN message may cause WildFly to shutdown)
I rechecked the logs which you attached earlier from http://perun.pmf.uns.ac.rs/mitrovic/files.zip
It looks like something happened during "09:19:17" to "09:19:53" interval. (around 36 seconds)
{code} 2014-08-14 09:19:17,587 INFO [org.jboss.as.server] (ServerService Thread Pool -- 65) WFLYSRV0010: Deployed "siebog" (runtime-name : "siebog") 2014-08-14 09:19:53,350 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 84) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory 2014-08-14 09:19:53,357 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000029: Passivating all entries to disk 2014-08-14 09:19:53,363 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 81) ISPN000030: Passivated 0 entries in 5 milliseconds 2014-08-14 09:19:53,372 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 79) MODCLUSTER000002: Initiating mod_cluster shutdown 2014-08-14 09:19:53,372 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 84) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'siebog#Radigost' {code}
If the issue is always reproducible at your end then can you take a set of thread dumps then it may be helpful to understand what activity was being performed during that time.
Running WildFly in debug mode may also be very helpful. Did some one stopped the server gracefully "09:19:17" to "09:19:53" interval.
Your application is deploying fine and accessible at my end with the following logs:
14:45:18,284 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /PATH/TO/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/fb/a02dce3cf734d9fd92e33984fc299d3ebc1e78/content 14:45:18,293 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "siebog.war" (runtime-name: "siebog.war") 14:45:18,539 WARN [org.jboss.as.dependency.private] (MSC service thread 1-2) WFLYSRV0018: Deployment "deployment.siebog.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice. 14:45:18,596 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0021: Registered web context: /siebog 14:45:18,754 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "siebog.war" (runtime-name : "siebog.war")
-
6. Re: Web context not registered in domain mode
jaysensharma Aug 14, 2014 5:54 AM (in response to dejanm)I tried in Standalone mode and the application was running and accessible
In domain mode the Web Components context is not being registered. Also noticed that the WARN appears only in domain mode.
{code}
[Server:server-two] 15:21:03,160 WARN [org.jboss.weld.Validator] (MSC service thread 1-3) WELD-001471: Interceptor method postConstruct defined on class siebog.server.xjaf.cnm.ConnectionManager is not defined according to the specification. It should not throw javax.naming.NamingException, which is a checked exception.
{code}
-
7. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 6:13 AM (in response to jaysensharma)That's also the situation that I'm getting - it works in standalone, but not in domain mode. I removed the "throws NamingException" from ConnectionManager's postContrustuct method, since it was an old signature anyway. But nothing changes.
Regarding the "09:19:17" to "09:19:53" interval, it was me who stopped the server, after verifying that it does not work. Sorry for the confusion.
-
8. Re: Web context not registered in domain mode
ctomc Aug 14, 2014 6:19 AM (in response to dejanm)by look at your log your application should be available at
if it works in standalone and not in domain, only thing different is port offset so you wont get your app at port 8080 but some other port, looking at the log will tell you exactly which one.
-
9. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 7:20 AM (in response to ctomc)Not sure what you mean. localhost:8080 opens the WildFly welcome page, but localhost:8080/siebog(/index.html) returns 404. The only two relevant lines that I can see in the log are:
Undertow HTTP listener default listening on localhost/127.0.0.1:8080
Undertow AJP listener ajp listening on localhost/127.0.0.1:8009
But in domain mode there is no message that the "/siebog" context has been registered anywhere. Also, the master node does not define any port offset.
-
10. Re: Web context not registered in domain mode
jaysensharma Aug 14, 2014 7:25 AM (in response to dejanm)Looks like your CLI command is wrong it is defining a wrong name to the deployment which is causing the deployment to not to start.
Your Command
deploy /home/dejan/dev/siebog/trunk/siebog/siebog.war --name=siebog --server-groups=xjaf2x-group
Correct Command Change the above to following: (make sure to use the same name as the name of your archive "--name=siebog.war")
deploy /home/dejan/dev/siebog/trunk/siebog/siebog.war --name=siebog.war --server-groups=xjaf2x-group
-
11. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 8:41 AM (in response to jaysensharma)Wow, I had no idea the name actually mattered
But with --name=siebog.war I cannot access EJBs nor services. This is the entire log of deployment:
INFO [org.jboss.as.repository] WFLYDR0001: Content added at location /home/dejan/dev/siebog/wildfly-9.x/domain/data/content/a5/e890fd99e81ee2e3c32c71580e78d0cb56f2fb/content
INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "siebog.war" (runtime-name: "siebog.war")
WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.siebog.war" is using a private module ("org.infinispan:main") which may be changed or removed in future versions without notice.
INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0021: Registered web context: /siebog
INFO [org.jboss.as.server] (ServerService Thread Pool -- 93) WFLYSRV0010: Deployed "siebog.war" (runtime-name : "siebog.war")
As if the archive is not enabled. Although the web admin console says it is. Disabling and enabling it does not help.
-
12. Re: Web context not registered in domain mode
jaysensharma Aug 14, 2014 8:57 AM (in response to dejanm)Looks like you the above output you copied from the Host Controllers CONSOLE output which appears in the terminal (Command Prompt). Did you check the server log ?
In your "server.log" you should be able to see the JPA and EJB deployment output including the Web Context registration messages.
-
13. Re: Web context not registered in domain mode
dejanm Aug 14, 2014 10:11 AM (in response to jaysensharma)The structure of my .war file was wrong. Using --name=siebog.war does solve the issue. Thank you for your help!
-
14. Re: Web context not registered in domain mode
ctomc Aug 14, 2014 10:45 AM (in response to dejanm)you can also add jboss-web.xml with <context-root>/some-root</context-root>
to make sure context root is always the same not matter what is the name of deployment