I have a multi-maven war project that I'm trying to deploy in Wildfly. I'm using the JBoss Tools plugin in eclipse to do the deployment (incremental, full publish) and I can see the files being deployed, updated in wildfly's deployment directory. My problem is the xhtml file rendered in the browser is not updated. What I tried:
1.) clear the browser's cache - no effect
2.) open a private browser window - no effect
3.) added a no-cache filter in wildfly
<server name="default-server">
<host name="default-host" alias="localhost">
<filter-ref name="cache-control" predicate="path-suffix['.html'] or path-suffix['.jsf'] or path-suffix['.xhtml'] or path-suffix['.css'] or path-suffix['.js']"/>
</host>
</server>
<filters>
<response-header name="cache-control" header-name="Cache-Control" header-value="no-cache"/>
</filters>
Seems like Wildfly has some deep caching, because when you run incremental publish and then restart the server the changes are reflected.
Any idea?
For standalone:
When already connected to CLI:
deploy /path/to/application.war
Connecting and deploying in a single command:
jboss-cli.sh --connect command="deploy /path/to/application.war"
Connecting, deploying, and authenticating in a single command:
jboss-cli.sh --connect --user=admin --password=redhat command="deploy /path/to/application.war"
For domain:
Deploying to all groups:
deploy /path/to/application.war --all-server-groups
Deploying only to specified groups:
deploy /path/to/application.war --server-groups=server_group_1,server_group_2
These domain commands can also be used like above to connect and/or authenticate in a single command.
User can not deploy application to specific server/servers in domain mode.
The application.war should be an archived application (not an exploded war).
Problem was solved by adding param: javax.faces.FACELETS_REFRESH_PERIOD in web.xml.
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>2</param-value> <!-- Should be -1 for production. -->
</context-param>
Related
After arquilliian test for our project, in wildfly standalone.xml the following entry is created.
<deployments>
<deployment name="cfgtest.ear" runtime-name="cfgtest.ear">
<content sha1="b0f9e180aaa4e14ee9bab37b4368b6ce45b7b156"/>
</deployment>
<deployment name="pcuitest.ear" runtime-name="pcuitest.ear">
<content sha1="884d1333731f6ed58eb47cee7d7a98a20829d373"/>
</deployment>
</deployments>
Ideally the above should be removed once all tests are completed and server is stopped, but thats not happening anyway. Now if I run the test for the second time - at the time of server startup the above deployments gets started and it creates conflict with the new war files of the current test.
Is there any way I can remove the deployments entry from standalone.xml so that it wont get started when the server starts again. Any startup commands to server so it removes all the deployments or something like that would be helpful.
Note: I found that, If I run the test from eclipse, deployed ear's removed automatically while server stop. But if I run it from gradle, issue remains.
Happy New Year to all.
I have a keycloak/wildfly question.
I am attempting to secure my war for WildFly 9.0.2.Final deployment. I follow the directions in section 7.2.1 of http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/pdf/keycloak-reference-guide-en-US.pdf
I get the error Unexpected element '{urn:jboss:domain:keycloak:1.0}subsystem
I have carefully followed each step as listed below.
cd $WILDFLY_HOME
unzip keycloak-wildfly-adapter-dist.zip
edit the standalone.xml and add the following:
<server xmlns="urn:jboss:domain:1.4">
<extensions>
<extension module="org.keycloak.keycloak-wildfly-subsystem"/>
...
</extensions>
<profile>
<subsystem xmlns="urn:jboss:domain:keycloak:1.0"/>
...
</profile>
It is the line subsystem xmlns="urn:jboss:domain:keycloak:1.0 that is flagged in the error.
What am I missing? Thank you in advance.
May be it's a little bit too late. I think the problem could be that you forget to merge modules, bins folder from key-cloak into Jboss, so that the container itself doesn't recognize the keycloak.
I am running my application using JBoss which is in windows7. Now I want to access the same application from other system which is having Ubuntu 14.04 OS. I saw some posts in the internet and I can able to access the remote JBoss & my application. But I am not able to Login. I am getting this error in the console
net::ERR_CONNECTION_REFUSED
I don't know what is the issue. Help me.
Thanks.
Normally Jboss is started to listen in localhost (127.0.0.1). On your standalone.xml file you will find something like:
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
So you can change your standalone.xml file replacing this 127.0.0.1 with 0.0.0.0, or you can edit (in your jboss/bin directory) standalone.conf.bat file and at some point add to your JAVA_OPTS the option -Djboss.bind.address=0.0.0.0, like:
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.bind.address=0.0.0.0"
You can even add this property on the standalone.xml file.
I have deployed my application in jboss 7. It is in the url www.myappurl.com/appname/.
But if I go to www.myappurl.com/index.html I see Jboss's landing page that says "Welcome to JBoss AS 7".
How Can I remove that page?
Basically you have to set to false the enable-welcome-root property of the Virtual Server that you are using and specify into the jboss-web.xml that the application is bound into the Root Web Context ("/").
See this tutorial.
Hope it helps. Francesco
you have to deploy an application that has Context Path set to /
UPDATE
Looking some resources on the internet such as this http://stephou.wordpress.com/2012/05/05/how-to-deploy-to-jboss-as7-default-root-context/ say that you have to modify first your standalone.xml else it will raise an exception.
From personal experience i just set the Context Path of my webapp to / (root) and it works just fine
you can remove these lines in the standalone.xml:
<location name="/" handler="welcome-content"/>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>
I'm working on Eclipse STS 2.7.2 with Java JDK 1.6, Windows XP SP3. I work behind a proxy which requires authentication.
I wrote two simple client and server plugins which work using DS and Zookeeper discovery. They refer to an IHello interface bundled in a third plugin.
The server publishes a simple Hello service which returns a string "hello" when invoked on 192.16.23.28:6666/hello and starts Zookeper with VM arguments
-Dzoodiscovery.dataDir=bla
-Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3030;clientPort=3031
xml is:
<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="NOLINKALLOWED" name="it.eng.test.remote.ds.helloservice">
<implementation class="it.eng.test.remote.ds.helloservice.HelloService"/>
<property name="service.exported.interfaces" type="String" value="*"/>
<property name="service.exported.configs" type="String" value="ecf.generic.server"/>
<property name="ecf.exported.containerfactoryargs" type="String" value="ecftcp://192.168.23.28:6666/hello"/>
<service>
<provide interface="it.eng.test.remote.ds.hello.IHello"/>
</service>
</scr:component>
the client starts Zookeeper with VM arguments
-Dzoodiscovery.autoStart=true
-Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3031;clientPort=3030
In both cases the OSGi framework is started with the -console -consoleLog -clean arguments.
I then created two separated run configuration for both server and client (Run as->run configurations..) adding all required bundles (most important ones: org.eclipse.ecf.provider.remoteservice and org.eclipse.ecf.provider.zookeeper) and their dependencies.
Based on that configuration I defined two separated product configurations (new->product definition->select run configuration) for both client and server.
Now, if I run them by clicking on the link "Launch an Eclipse application" inside the respective product configuration, everything works. The server publishes the service, the client gets it and shows "Hello" on output. netstat -a | grep 6666 shows that someone is listening on that port and netstat -a | grep 30 shows that port 3030 and 3031 are being used.
Eclipse is configured to use my proxy correctly.
If I export them as an Eclipse product based on the aforementioned configurations (export->eclipse product->select product configuration), I get two folders: client and server.
Inside them there's everything needed to run the applications inside an external OSGi framework, including configuration files for both the framework (config.ini) and the VM (eclipse.ini).
The applications are started with STS.exe -console which opens an OSGi console with all the required bundles installed and started.
Starting the server works, I see someone listening on 6666 and zookeeper reports that the service has been published.
If I start the client, nothing happens. No output, no connections on 3030 and 3031, no errors. It simply does nothing, zookeeper however says it has started discovery.
Using localhost instead of my IP changes nothing, it still works inside Eclipse but not outside.
The exported application had its configuration stored in: ./eclipse.ini and the OSGi framework configuration was in ./configuration/config.ini
eclipse.ini contained the parameters needed by the Java VM for zookepeer to work:
-consoleLog
-console
-clean
-vmargs
-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dzoodiscovery.autoStart=true;
-Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=localhost:3031;clientPort=3030
Launching the application was ok but that file wasn't read.
manually launching the application as:
java -Dzoodiscovery.autoStart=true; -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone=192.168.23.28:3031;clientPort=3030 -jar org.eclipse.osgi_3.7.0.v20110613.jar -console -configuration c:\temp\zooc\configuration\
from within ./plugins where all the jars were worked.
Guess the .exe made automatically by Eclipse wasn't well configured to read its config file.