I am using WELD 2.4.1.Final for my web application running on Tomcat 7. I am having JSF and Jax-RS Rest services in my web application. I have implemented asynchronous JAX-RS Rest Services. Async Rest call works perfect, but in logs I got following Warnings :
WELD-000715: HttpContextLifecycle guard not set. The Servlet container is not fully compliant.
WELD-000714: HttpContextLifecycle guard leak detected. The Servlet container is not fully compliant. The value was 1
WELD-000335: Conversation context is already active, most likely it was not cleaned up properly during previous request processing
I got from this website : http://weld.cdi-spec.org/documentation/, that these are issues from Tomcat.
Should I consider them or just ignore? If I ignore, does it affect performance of my web app? Is there any Workaround to get rid of this warnings?
Related
I have Embedded Jetty running which has reverse proxy servlet mapped for a particular URL. For ex: http://url1/abc is reverse proxied to http://url2. This works great, whenever someone calls http://url1/abc, data is served from http://url2.
I want to achieve the same using quarkus. Is this possible to do it in Quarkus? I think one of the option is to write own code in ContainerRequestFilter but I am looking more for OOTB support just like jetty. Can somehow undertow be leveraged here?
Please help.
UPDATE 1
I tried to do it through undertow-handlers.conf (placing it in META-INF folder). It worked well for redirect and rewrite but throwing error for reverse-proxy:
path-prefix('/a') -> redirect('/b)
path-prefix('/a1') -> rewrite('/b1')
path-prefix('/a2') -> reverse-proxy('http://localhost:7100/b')
If I have first two only, quarkus is started successfully and requests are served correctly. If I started using third one, quarkus start gets failed with below error.
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string no handler named reverse-proxy known handlers are [disallowed-methods, allowed-methods, jdbc-access-log, secure-cookie, access-log, mark-secure, response-rate-limit, canonical-path, response-code, disable-cache, ssl-headers, trace, blocking, url-decoding, access-control, redirect, set, ip-access-control, request-limit, resource, restart, clear, byte-range, done, rewrite, forwarded, stuck-thread-detector, jvm-route, learning-push, dump-request, proxy-peer-address, resolve-local-name, header, store-response, path-separator, resolve-peer-name]:
Although, I see undertow has reverse-proxy handler, not sure why it is not working for me.
http://undertow.io/undertow-docs/undertow-docs-2.0.0/index.html#predicates-attributes-and-handlers
I think the main issue is of dependency here. I see io\undertow\server\handlers package in my app libs but not io\undertow\server\handlers\proxy where I think the reverse proxy code is present.
How can I pull this dependency in my app?
Context: Existing JavaSE application written in Swing which fires up an embedded server (so far it was Jetty) but we need to switch to Java EE, so we thought about bringing in an enterprise container (candidates are: Payara, Tomee, Wildfly).
The server should be able to run a web app based on dynamic input: web context, with its own web.xml, specific web resources which are not known at build time, so uber jar is not really an option for us.
We have successfully started a web app on Payara using code like the following (this is not working code, but it shows the steps we took for using Payara)
GlassFish glassfish;
WebContainer container;
GlassFishRuntime glassfishRuntime = = GlassFishRuntime.bootstrap();
glassfish = glassfishRuntime.newGlassFish();
glassfish.start();
// Access WebContainer
container = glassfish.getService(WebContainer.class);
WebContainerConfig config = new WebContainerConfig();
container.setConfiguration(config);
Context context = container.createContext(contextPathLocation);
m_webAppContexts.put(p_contextName, context);
WebListener listener = container.createWebListener("listener-1", HttpListener.class);
listener.setPort(myDynamicPortNumber);
container.addWebListener(listener);
container.addContext(context, myDynamicContextPath);
context.addServlet(myDynamicMapping, myServletName);
This is all working and a basic web application starts in Payara when invoked from our Java SE application.
We also have a fragment of web.xml declaring additional servlets that we want to bring in this dynamic deployment if given conditions are satisfied.
What is the best way to override the existing web.xml with fragments from another web.xml? We need pointers to documentation, directions from more experienced Payara users.
This is not possible with Payara or Wildfly, as they work very differently from how Jetty works.
However, it is possible with Tomee.
I am getting an exception as given below.
I want Response class to be loaded from jawax-ws-rs.api.jar.
but its getting loaded from the j2ee.jar and throwing the below error:-
java.lang.NoSuchMethodError: javax/ws/rs/core/Response.readEntity(Ljava/lang/Class;)Ljava/lang/Object
Is there any way we can skip loading of j2ee.jar at startup of WebSphere?
Your question is incorrect, probably what you really want is to replace JAX-RS engine provided with WAS with some third part. And you should never pack j2ee.jar with your application as all required classes are already loaded by the server.
Check the following posts and links:
JAX-RS Jersey 2.10 support in Websphere 8
Disabling the JAX-RS runtime environment
My app ([URL]) is not responding. I have gone through the recommended steps on your site.
I have deployed this war to my local tc-server and everything is working there (/people-server/rest/persons/). I would expect to get some xml back from [URL]/people-server/rest/persons/.
Please advise
Darren Leung
Your app is actually responding to http://[URL]/_stax/status, which implies the container is able to receive and handle requests properly.
Since your app is returning 404 for /people-server/rest/persons path requests, this implies that there are no Servlets currently loaded by the container to handle those requests. There are two main reasons that your app may not have servlets configured at runtime:
You have not configured your app with Servlets properly to handle these requests (this is typically done via servlet and servlet-path entries in WEB-INF/web.xml)
There was an error that occurred during the startup sequence of your app that prevented the container from loading your configured Servlets.
To determine if there is an error, the first thing you should check is the logs for your app. Since you didn't post any errors, I'll assume that you checked the logs already and did not find any errors.
This leaves you with the scenario that you don't have any Servlets configured to handle the requests. After seeing your URL, I noticed that it is prefixed by /people-server, which looks suspiciously like a context-path prefix you may be using in your locally configured TC server. Since apps deployed on CloudBees run at the root context-path, I tried using the following URL and see that it is indeed responding:
[URL]/rest/persons/
This implies that you do have a Servlet configured for handling /rest/persons/ paths, which means you are encountering a slight difference in URLs expected in your local environment vs your deployed environment.
If you want this Servlet to be available at /people-server, you will need to update your web.xml to use this prefix for the path used by your REST Servlet. Alternatively, you can deploy the app as an EAR file with an application.xml that uses a context-path of /people-server for your webapp archive.
As a general rule - 400 type errors (eg 404 in this case) indicate a problem with the app almost always - and are typically related to path errors and mapping.
500 type errors mean there is an unhanded error in the application, this is as per:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Some causes of them could be if the application is slow to start, there can be a short period of time where there are some errors, 504 if the application (all instances of it) are very very slow (too slow).
If there is a persistent 502 happening this can indicate a platform problem in some cases (ie requests are not reaching your application).
You can often see errors in your apps log (bees app:tail will stream this - or use the console).
If your app uses JAX-RS to serve rest content on a jboss ("JavaEE 6 Web profile") container, you need to enable container support for this feature. Just add this servlet declaration to your web.xml
<servlet>
<servlet-name>jax-rs</servlet-name>
<servlet-class>javax.ws.rs.core.Application</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jax-rs</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Your IDE may warn javax.ws.rs.core.Application is not a servlet, and that's indeed a strange detail from JAX-RS API, but that's the correct class to be used.
I have a problem running a Java (using Metro) client against a .NET STS and secured web service. However, when I run my .NET based client, it always works.
As you probably already know, when a JAX-WS client is ran, it requests metadata from the service during runtime (even though it already has ran wsimport during design time). However, it seems that this runtime metadata request is where my problem is.
The problem that I'm facing is that during the runtime requests of metadata, some WSDL's exported by my WCF service caused the Java client to just 'hang' during the mex requests. When it hangs, it doesn't even get to the point of issuing the RST request.
For example, I can get to a spot where I have 9 [OperationContract] attributes and it works. But when I add a 10th service method, it doesn't work. However, if I remove one of the 9, then it works. I know there isn't a problem with a particular method because I can mix and match and the same pattern holds.
I can't seem to deduce a pattern or reason for why some WSDL's work and some don't. I strongly doubt there is a limit to the number of service methods. However, could this be a problem with "overall complexity" with the exported WSDL?
Does anyone have any ideas? Have anyone run into this issue before?
If more information is needed, I can glady post it. I'm just trying to keep the initial post a manageable length.
I will also add that I'm running the STS and secured web serivce in .NET 4, and they are based on WIF (so I don't have to worry about security settings). My .NET client is also .NET 4. On the Java side, I'm using Netbeans 6.9.1 with Metro 2.1 running Glassfish 3. I've verified that I receive the same issue running on Metro 2.0.
Please see WSDL Requests with Metro/JAX-WS/WSIT During Runtime for a detailed answer.
Following the example given, there're chances that MaxMessageReceivedSize or MaxStringContentLength limit is reached. Have you tried increasing the values of MaxMessageReceivedSize and MaxStringContentLength for binding? You can try enabling WCF traces, there'd be a warning logged if any such limit is reached.