Show maintenance page during Wildfly startup - wildfly

I have a WildFly installation which takes some time during startup due to the count and size of the deployments. So I would like to show a maintenance page until the full application is ready.
In one of the previous WildFly versions I used default-web-module as configuration option and registered a small WAR file, which was visible right away and was replaced as soon as the big application was available.
Unfortunately this is no longer possible with WildFly 22, instead an exception is thrown as soon as the real root application is deployed:
org.jboss.msc.service.DuplicateServiceException: Service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService is already registered
I know that I could put a small web server (nginx or similar) in front of WildFly to return my maintenance webpage as long as WildFly returns a 503 error. The only thing which prevents that is the fact, that the maintenance page still contains some logic which I would need to emulate on nginx.
Is there any other option which ensures that my maintenance page is delivered immediately while the other apps are still starting?

If I do understand your question correctly, what you want is to show error page of status 503 when server is down or 404 when server is replacing deployments.
But for your environment which don't have a web server in front of application server, we just need to consider 404 situation.
503 is for web server when the application server is down, therefore, 503 service unavailable.
First: Console -> Configuration tab
Head over to management console of Wildfly. And depends on what mode(domain or standalone) you are using ,there will be a little different inside configuration tab.
Second: Configuration -> Web -> Filters
If using domain mode, choose the profile you are using it.
And head over to Subsystem -> Web(Undertow) -> filters -> click 'View'.
I used profile 'full' in my local machine with domain mode, therefore, this is what my console looks like.
Path_to_Filters
Third: Choose Error page tab inside Filters
Set code and path like this, where code is what status code you hope the static page to show. And path is the file location of your static page.
setPathAndCode
You can see Wildfly doc for error-page settings.
Fourth: Configuration tab -> Web(Undertow) -> Server -> default-server(or what you used)
HeadToServer
Fifth: Choose Hosts tab inside servers
Choose 'Hosts' tab, and click add filter button.
Select the filter we just set in step three, and set predicate to true.
I'm not sure what will be effected if didn't set as true or left empty, cause it's not required fields.
Last: Restart the server in order to let your configuration works.
Now you should able to see your static page showed when you undeploy or re-deploy your application.
Sorry for not answering in too good answer format because I didn't answer any questions before.
** You can also set your standalone.xml or domain.xml like this to get the same result.
setXmlFile

Related

Jazz: Context root not found

I'm pretty beginner with the whole RTC concept, so I have started a server:
Server clm is started.
The clm server was started.
I am trying to login to jazz admin page to configure the setup, the url I'm using is:
http://[fully qualified hostname]:9080/jts/setup
http://[fully qualified hostname]:9080/jts/admin
I get the "Context root not found" page, not sure where am I going wrong. Then again I found a URL for Liberty admin center page ( not sure why is it used). But I gave it a try
http://[fully qualified hostname]:9080/adminCenter
I can open the page, but i do not have the login credentials. It is pretty confusing, if anyone can guide me through it'd be helpful.
From this thread:
The context root being accessed is /jts... and jts is a default context root for JTS (refer to Installing the Rational solution for Collaborative Lifecycle Management by using IBM Installation Manager).
Unless a different context root was entered during the installation, I would expect /jts to be the context root for JTS application.
%CLM601_DIR%\server\liberty\servers\clm\conf\application.xml has information about the application being deployed.
It should also show application context roots as well.
Can you access /jts/scr or any other applications such as /ccm/scr, /qm/scr, etc?
If not, that could be that the applications are not deployed OR they did not start up successfully.
You can check logs such as console.log, jts.log, etc in %CLM601_DIR%\server\liberty\servers\clm\logs and see if any errors are there.

Bluemix SAML and timeout session issue

I've created Web Application running on Java Liberty Runtime on Bluemix. Login is done by using SSO service with SAML enterprise provider. After login user redirected to my app and on every JAX-RS request I get user's credentials by following code:
Subject s = WSSubject.getCallerSubject();
Object credential = s.getPrivateCredentials().iterator().next();
String loginToken = credential.toString();
Everything works fine, but if the user has been idle for more then 10 minutes and then perform any ajax request WSSubject.getCallerSubject() returns null, and I required to refresh application.
I've tried to increase timeout by adding following attribute to web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
But it didn't help. So I'm looking how can I increase timeout or possible I can retrieve user credentials in a different way?
You need to add the optional element <authCache> to the server.xml file to change the default values for the authentication cache.
As you mentioned in your question, the default value is 10 minutes. To change it to 60 minutes you need to include the following in the server.xml file:
<authCache initialSize="50" maxSize="25000" timeout="60m"/>
The documentation here provides more details and also explains initialSize and maxSize options, I left the default value for these two above and just updated timeout.
If you are deploying your application using the default method of pushing the war file, you will need to use a different approach to deploy the application with a custom server.xml file. Please check the documentation here for options on pushing Liberty profile applications (more specific check sections Server Directory and Packaged Server).
In this case, you may also want to check the server.xml file that is currently deployed and modify that version to add the <authCache> element.
You can get a copy of the file by running the following command:
$ cf files <your_app_name> app/wlp/usr/servers/defaultServer/server.xml

WSO2 Class Mediator gives an error

Our team is completely new to the WSO2 tool. We got the basic training on how to add proxy services and were able to do so as well.
Now, we have to add a class in the In Sequence. We tried that using the Class mediator but it was not able to find the class. Then we realized that the jar file needs to be in the components/lib folder. So, its able to load the class now. It proceeds to the out sequence and fault sequence properly. But, in the end, it gives the following exception.
Unable to add proxy service :: Failed to add proxy service: Parse. Check whether the Proxy already exists-Failed to add proxy service: Parse. Check whether the Proxy already exists
So far, we're using the design view to configure it. I surveyed through most of the posts within this forum, and, all are using the source code to configure. Also, the proxy service is not present in the Source View section under Service Bus.
Are we missing any step in the configuration? Do we need to switch to coding method or it is possible this way.
Your explanation is strange. Above mentioned error log can appear at the time of deploying the proxy service. But you say your proxy is going to the out-sequence and fault-sequence. From that what I understand is the proxy is already deployed.
You can check whether a proxy with the same name is there by looking in the ESB_HOME/repository/deployment/server/synapse-config/default/proxy-service folder. If there is a file with name Parse.xml (I think the name of the proxy service is Parse) you can delete it from the file system and then go to the design view and add the proxy again.
It seems there is already a proxy with the name you provided. Go to WSO2 ESB "source view" and check whether there exist a proxy with that name. Source view is available on the left side of the management console.
This artical will take you step by step in writing custom class mediators.
This post may also be relevant for you.

Activation pending in CQ5

I have created a test page in the Geometrixx site in CQ5. I can see the page very well on 4502 port (author environment). But when I activate the page to see it on the 4503 port (Publish environment) , I always see the yellow colored icon in front of the page on console which on hover says 'Activation pending. #1 in Queue'
Is there some workflow attached to it ? If so, how can I check it out and probably kill it (for now) ? Or is there some other reason ?
The default replication queue settings points to localhost:4503. If your publish instance is not located on the same machine as the author instance (which is common), you will need to change the settings to point to a valid publish instance. Once a valid publish instance is configured the items queued for activation should get processed and the icons will change from yellow to green.
If the queue is blocked, you can clear it by:
going to /etc/replication/agents.author.html
Clicking on the default replication agent.
Then clicking on 'clear' above the queue. This will clear the entire
queue.
If you want to clear one or more specific items in the queue, you can select
them then click clear.
This page has a few steps on troubleshooting replication agents:
http://helpx.adobe.com/cq/kb/replication-stuck.html
This page has some general information about replication agents:
http://dev.day.com/docs/en/cq/current/deploying/configuring_cq.html#Replicating from Author to Publish
You can inspect the replication queues at
http://localhost:4502/etc/replication.html
The default agent is
http://localhost:4502/etc/replication/agents.author/publish.html
From here you can test the connection, view the log, and see what's in the queue. You can also clear the queue or force retry.
there is a way to see a "final View" of your test page without to publish: wcmmode=disabled
http:// localhost: 4502/cf#/content/geometrixx/folder/test.html
Just delete /cf# and add ?wcmmode=disabled after the extension.
http:// localhost: 4502/content/geometrixx/folder/test.html?wcmmode=disabled
One thing not explicitly mentioned so far: You need TWO instances of AEM running. Ports 4502 and 4503 don't point to different modes of the same instance, as AEM only listens to the one port (in general). So you will need to copy your Author jar to a new directory and name it something like cq5-publish-4503.jar
In addition, you may need to update your maven pom files for code deploys. You CAN set installed bundles on author to auto replicate/publish however.

How to change default start page of Glassfish?

Currently when I type in the URL of my webapp, say "http://abc.edu/mywebapp/", I am taken to the login page of my webapp. When I type "http://abc.edu/", I am taken to the GlassFish info page. How can I do it such that when I key in "http://abc.edu/", I will be taken to my login page and not the GlassFish info page?
Option 1: You can set one of your webapps as default. This can be done with the admin console:
Configuration --> Virtual Servers --> server
Then select your default web application from the drop-down menu. If your webserver port is 8080, you can start your application now by:
http://hostname:8080
instead of http://hostname:8080/webapp
Notice that "server" is the name of Glassfish's default virtual server. If you configured a different virtual server for your webapp you need to change it accordingly.
Furthermore regarding this source, there might be some problems with JDBCRealms.
Option 2: You could also deploy your default webapp to "/" instead of "/webapp" but I think the first option is more flexible.
You need to change your context root to "/" Edit the application.xml that is where the context root for the app is set. You might have to undeploy the default context root inorder to do that (that is what I do in JBoss, I undeploy ROOT.war).