I am using an embedded version of jetty 7 to load a web application using Apache MyFaces 1.2 in a junit 4 test class on the advice from another thread.
While running the test i get this error.
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
This application works fine with tomcat, weblogic and even oc4j!
How can i get this to work with jetty?
I solved this by adding the myfaces-impl jar which had the .tld file inside the WEB-INF/lib directory.
Related
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 using Apache Tomcat 8.5.12 with JOSSO single sign on .
After configuration I can not start the tomcat server and I get this error.
Everything is well configured.
Does anyone have an idea that can help me to start the server ?enter image description here
Apache Tomcat 8.5 doesn't play nice with the JOSSO Agent for Apache Tomcat 8 as the former has changed the approach for hooking into the event bus. Therefore, an ad-hoc SSO agent is needed, included in an early access release of JOSSO 1.8.12, available here for download : https://github.com/atricore/josso1/releases/tag/1.8.12-rc1-release
A binary distribution is included, hence there's no need to build from the source.
In order to install it, make sure to manually replace the "old" agent artifacts - namely the JOSSO Agent for Tomcat 8 JAR files - with the ones that ship with 1.8.12 RC1.
As far as configuration is concerned, the following changes in the $CATALINA_HOME/lib/josso-agent-config.xml descriptor need to be applied for the JOSSO Agent for Apache Tomcat 8.5 to be instantiated.
From:
<bean class="org.josso.tc80.agent.CatalinaSSOAgent" name="josso-tc80-agent">
To:
<bean class="org.josso.tc85.agent.CatalinaSSOAgent" name="josso-tc85-agent">
As of the JOSSO server component, there is no need to perform any upgrade nor configuration change.
We have externalized the logback configuration in our spring app.
Used logback spring ext
compile 'org.logback-extensions:logback-ext-spring:0.1.4'
Added following lines in web.xml
<context-param>
<param-name>logbackConfigLocation</param-name>
<param-value>file:/${log-config-folder}/api/logback.xml</param-value>
</context-param>
Placed logback.xml in the folder mentioned in web.xml
/usr/me/my-app/log-config
/api
/logback.xml
Added JVM argument in start up script of tomcat.
JAVA_OPTS="$JAVA_OPTS -Dlog-config-folder=usr/me/my-app/log-config"
When the app is deployed in tomcat, it works perfectly fine. We are able to see the logs. When logback xml gets updated, I can see changes reflecting immediately in the app (changing LOG LEVELs)
Problem: When this same configuration is moved to weblogic, its not picking up the logback xml from external folder. JVM argument is added to weblogic start up script. I can see the JVM argument getting set.
Weblogic team came back and told they have made the weblogic setting to prioritize application classes and config.
<prefer-web-inf-classes>true</prefer-web-inf-classes>
Any pointers to triaging this would be really helpful.
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 am trying to connect to GlassFish 3's JMS service from a standalone remote client. However I am getting a java.lang.ClassNotFoundException: com.sun.messaging.jms.ra.ResourceAdapter. Any ideas on how to fix this?
Here's my setup so far:
Glassfish 3 JMS Service in LOCAL mode (I am assuming that EMBEDED mode will not work in this case because it bypasses the network stack)
JNDI properties are specified as follows:
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
gf-client-module.jar (in GLASSFISH_HOME/modules) added to the standalone application's classpath. Also tried adding other jars present in the modules directory (such as jms-core.jar), but still getting the same ClassNotFoundException.
Any help would be much appreciated.
Instead of using all of the individual Glassfish jar files that you might need (such as gf-client-module.jar, imqjmsra.jar, and imqbroker.jar), the preferred method is to use the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib.
There is more information at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. That document pertains to using EJBs in standalone clients, but the solution is the same for using JMS.
Ok. I found a solution. See here for details, but the short answer is that I needed to add two jars to the classpath: imqjmsra.jar and imqbroker.jar. These were available inside a rar called imqjmsra.rar which can be found under glassfish's mq directory. I had to extract the two jars from this rar!
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
As mentioned in the Ivan A Krizsan's notes for the EJB certification, and depending on the Glassfish version, this should be enough:
GlassFish 3 (and GlassFish 4 too, I've just tested it): $GLASSFISH_HOME/lib/gf-client.jar
GlassFish 2: $GLASSFISH_HOME/lib/appserv-rt.jar and $APS_HOME/lib/javaee.jar