Develop Reference

Skip deploying or stop web application if servlet context initialization fails

In our project, we have several Spring-based modules which are deployed on WAS as web applications. We need to skip deployment, or stop a module if its Spring context initialization fails (i.e. ContextLoaderListener#contextInitialized or DispatcherServlet#init throws an exception). Now, if such happens, app is got deployed and starts, but returns HTTP 500 for any request.
Websphere 8.5.5
Related question: https://stackoverflow.com/a/272747/3459206

This APAR seems to be relevant:
https://www-01.ibm.com/support/docview.wss?uid=swg1PI58875
From the APAR text:
Listener exceptions typically should not stop the application
from starting up for service. However, some applications depend
on their listeners to do the necessary setup before the
application is started for service. Such applications prefer to
stop the application from starting up when there is any
exception in their listeners.
Problem conclusion
The WebContainer Container code was modified to provide an
option to stop the application when there is any listener
exception during the application starting up process.
A new WebContainer custom property needs to be set to enable the
behavior provided by this APAR:
For Full Profiles
com.ibm.ws.webcontainer.stopappstartuponlistenerexception = true
(default is false)
For Liberty Profile
stopappstartuponlistenerexception=true
The fix for this APAR is currently targeted for inclusion in
WebSphere Application Server fix packs 8.5.5.11 and 9.0.0.2,
and Liberty 16.0.0.3
See the APAR link for additional information.

You can use jenkins + maven.
Add the part you need to check under your test like junit.
Then if this module do not pass test, jenkins would not deploy it.
But I prefer fix bugs before deployment

Had a very similar issue.
The thing is - webfear - sorry could not resist ;-) does not initialize everything on startup.
To trigger a controlled request, I added a ScheduledEJB to the startup of the application. This bean itself triggered a http-request to a defined URL, which itself triggered:
any filters to get initialized in the chain
any contexts which are needed are initialized
And this itself ensured that my application (EAR or WAR) got very quickly tested after deployment. This works well with some small amout of requests per minute
If you work with high load, means tons of requests per second, you need to choose a different approach.
In this case I added a polling mechanism into the #Startup of the application, which polled every second or 250ms (depends on the load of the application).
This firing to the server ensured, that my #Startup bean was the very first which triggered the possible init issues in the application. If this happened I initialized a filter which always reported a 500 (or better fitting error) to the requestor.
Of course stop your firing bean, as soon as you get the 500, else your admins may like to kill you. (happend to me, since I produced tons or monitoring issues ;-) )
And of course on the regular operation, after your application started properly, you should also disable the polling

Look for a try-catch in the top level of your application code that is catching the Spring exception and allowing the application to continue running.
If the Spring exceptions being thrown are permitted to propagate to the top of the stack, the JVM will stop and there's no way it can keep running, far as I know.

Strange behaviour of Tomcat 8.0.32: sometimes it ignores cookies. Can it be somehow debugged?

There is a very weird problem with our Tomcat 8.0.32 installed under Ubuntu 16.x.
This problem starts to happen accidentally and exists until tomcat server restart (so it is reproducible after it begins happen).
What happens, is that some of the requests send by timer from JS application with proper cookie: JSESSIONID= value are improperly processed: the Tomcat can not find Session object for it (from Spring MVC layer it means, that user is not authenticated). All requests with the same JSESSIONID being sent before this broken request, and all requests being send after (again with the same value of session id) - they all work fine!
We also certainly see that all headers in that request are correct (they are printed out by our application in some Filter), but Session object is not restored.
So basically it sounds like under some circumstances the Tomcat starts ignoring JSESSIONID from the requests sent via redirect from another server. And again, this does not happen always, only after some time of web-application life.
I will not provide any code here or configuration settings. First, because it looks like the poor Tomcat problem, second, because configuration is standard (out of the box after apt-install).
My question is: how can we configure the Tomcat in order to log all operations related to the JSESSIONID processing? Like that it finds session for the given ID, or does not and so on.
UPD: This never happens with more newer version of Tomcat 8.5.5. But due to some reasons it can not be updated on that particular server. My current goal is to collect evidences about this behaviour to be sure that it is a bug, or some strange default configuration that tomcat installation.

According to the docs https://tomcat.apache.org/tomcat-8.0-doc/logging.html
to enable debug logging for part of Tomcat's internals, you should configure both the appropriate logger(s) and the appropriate handler(s) to use the FINEST or ALL level. e.g.:
org.apache.catalina.session.level=ALL
java.util.logging.ConsoleHandler.level=ALL

Faces Servlet Application URL JSF/Glassfish

So I have let's say an application named MyApplication. I deploy it with a virtual server on glassfish and all is well since I set the default welcome page. Let's say the virtual server is to listen on mydomain.com
I goto mydomain.com and i see my index file of my application just fine. Then i go to do a j_security_check login.
And i am then redirected to: http://mydomain.com/MyApplication/page.xhtml
How can I get this to wehre it is: http://mydomain.com/page.xhtml ?
Now if I do take MyApplication out of the URL and try to manually goto that page it is blank, as I believe it is not being processed by JSF.
What I have tried.
* Setting the default glassfish application to my application and setting the context path of my application to / (glassfish complains and i cannot deploy my application)
* Doing the same as above without setting my context path to / and leaving it as is.
Will deploy but same issue.
My main reason for wanting this, is it seems if someone does get redirected to a path without the application name, the session state appears to be different. And causes some sporadic issues with session collision and values not being passed properly. So I either want to force the URLS to use the ApplicationName all the time, OR force them to not use it for the sake of consistancy.
There should be a way to accomplish this since I dont believe we should always have to have the ApplicationName in the URL.
Please help if you can, what I have found by searching seems to take care of it for the initial request but not when doing redirects using the FacesContext extenralContext redirect.
Unless I am not redirecting properly. I am at a loss here.
Thank you for the help.

IMHO you should consider using asap PrettyFaces
Your application URLs will always be elegantly displayed to your users.

Using 'SEARCH' or 'PATCH' with jetty

This basically has me at a loss, and has for almost a week. I'm working on a part of company architecture, trying to get REST all set up. There are two methods that are not in the javax.ws.rs package - SEARCH and PATCH. I've created the following interface in our project to implement SEARCH: (mostly a copy/paste from examples)
/** imports and such as appropriate **/
#Target({ElementType.METHOD})
#Retention(RetentionPolicy.RUNTIME)
#HttpMethod("SEARCH")
public #interface SEARCH {
}
The code using this works flawlessly if called against it directly. However, the web service that talks to the main service fails every time with 500 Invalid HTTP method: SEARCH. So, to be clear, there are two web-enabled services. The first that uses the above code works fine. The second, which is supposed to be nothing but a proxy to the first service fails.
The second service that is having the problem runs on jetty. The servlet that is doing the proxying is an extension of org.mortbay.servlet.ProxyServlet - the only overrides are on init and proxyHttpUrl to do a little bit of URL tweaking. I know that the second service doesn't pass the response into the first because I can shut down the first and the second still gives me that error back.
My question is, am I missing configuration pieces to enable "custom" (i.e. not in the javax.ws.rs package) http methods?

First off, that proxy servlet code is very old, from jetty-6 unless I am mistaken. We have released jetty-9 now, and the last three versions of jetty have come from eclipse so the ProxyServlet you ought to be using is the org.eclipse.jetty.servlets.ProxyServlet class.
Now, from jetty-7 on we added some customization to that proxy servlet so you could modify much more of the client exchange...and you might need to make use of that to get additional http methods working. It could be that the http-client only excepts standard http methods in which case we would have to fix that up for your use case (open a bug at bugs.eclipse.org under RT/Jetty if that is the case).

How to pass data from an application to a JCA resource adapter?

I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA.
Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to.
The data I need to get to the RA is
the port it's supposed to listen on,
the license used for the whole application (the feature the RA supplies requires extra licensing)
additional configuration data stored in a db
I've come up with four ideas:
Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that
Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.
But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)
Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.
The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.
Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!
Thanks and cheers,
Julius

In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.

The solution I finally came up with is to use the #ConfigProperty annotation. This means I use option one of my question above.
So my ResourceAdapter class looks like this:
public class Hl7ResourceAdapter implements ResourceAdapter {
#ConfigProperty
private Integer port = null;
// Rest from ResourceAdapter interface omitted here...
// Use port here to open socket...
}
The #ConfigProperty fields can now be set through either
a resource-adapter-config
the ra.xml deployment descriptor
Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)
A few additional notes:
We deploy the resource adapter's .rar file into the .ear of the application using it.
We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.
Hope this helps. kutuzof, will this get you any further?